4 ms·
Huh, what I usually do is generate a new SSH key on the dev box and enroll it. That means if the dev box gets compromised, first, it can't access anything other
by geofft 5y ago
Huh, what I usually do is generate a new SSH key on the dev box and enroll it. That means if the dev box gets compromised, first, it can't access anything other than my git server, and second, I have independent audit logs of actions from my dev box's key.
What's the advantage of using SSH agent forwarding over either generating a new key (if you don't quite trust the remote box) or scp'ing your private key (if you do trust the remote box just as much as your local one)?
- mjochim 5y agoIf you don’t really trust the remote box, then storing a key on it – even one created solely for that box – might not be a good option. Doesn’t really matter whether the key is completely and permanently unencrypted or you only decrypt it during use. To my understanding, by forwarding the SSH agent you can keep the private material on the local box only. I’d have to read up the details before I could be sure this is true, but that’s also what the linked article says: > The [...] ssh-agent [...] supports [...] a way to forward access to private keys to remote hosts, without exposing the private keys themselves. Creating a separate private key solely for this box – but storing it locally – is then a measure you can take additionally.
- raffraffraff 5y agoWhen you're forwarding an agent the material itself is kept on your local client, but if someone has root on the server that your agent is forwarded to, they can hijack your ssh-agent socket and ssh to any other server "as you", and your local ssh-agent will comply with the request and forward the key. There's a "lesser of two evils" argument you could make: by using a separate key that only has rights to git, you're protecting your "main" ssh identity from being hijacked. So the only thing they can do if they compromise the server is impersonate you on git. ...Exactly, that's arguably as bad as it gets. If you don't trust the jump box, do not use it. I had to use a "meh" jump box in a previous job. It was locked down to an extent, but a bunch of people could easily get root on it. Since I had to be active on that box for a bunch of work (not just "passing through" for the duration of a git pull) I set a very short lifetime on my ssh-add, so I got prompted for my passphrase whenever it expired and a key was requested. Not great, but better than leaving it active continually while I'm connected.
- tedunangst 5y agoNobody can break into the dev box and steal the key while you're away on vacation for two weeks.
- geofft 5y agoBut they can break into the dev box and inject malware (where by "malware" I mean like 'echo alias ssh=/tmp/evil-ssh >> ~/.bashrc') while I'm on vacation for two weeks, though? And if I wasn't going to notice them breaking in while I'm away on vacation, can't they just break in again as soon as I return from vacation? A computer isn't like a house. You don't inherently notice people breaking in when you're using it: they don't make sounds or show up in your line of sight. And you don't inherently fail to notice people breaking in when you're not: if there are logs (that get sent off the machine), there will still be logs when you get back. Digital burglars don't have any need to "scope out" your machine and "wait" for you to be on vacation. That's why I think the ssh-agent model provides a false reassurance. The fact that you're actively connected to the machine doesn't make attacks any less likely, but it sure feels that way, and so you're likely to forward an agent to a machine where you wouldn't be comfortable forwarding the raw key - but you shouldn't be comfortable forwarding the agent either.