35 ms·

Hum, I think you're missing some detail too. When agent forwarding is active, root can use that listening socket to authenticate evil connections while you're l

Hum, I think you're missing some detail too. When agent forwarding is active, root can use that listening socket to authenticate evil connections while you're logged into that machine. I'm actually surprised OpenSSH doesn't yet print a large warning when you go to connect and forwarding is enabled. All Mallory must do is rifle through your known_hosts (or bash_history if hashing is enabled), wait for you to connect, then su to your account, fix up the environment, and SSH to some boxes of yours, and update your authorized_keys there to let him connect while you're offline, or starting up a quick background netcat and disconnecting. This requires no magic tools, and syslog/lastlog on the remote machine won't show much of interest, especially if you're like me and rely on logging in multiple times "quickshot" to remote hosts, except for remote host names the lastlog is basically unreadable already.

there 15y ago
I'm actually surprised OpenSSH doesn't yet print a large warning when you go to connect and forwarding is enabled. agent forwarding is not enabled by default, so if you've turned it on, you should know what you're doing. it should only be enabled in ~/.ssh/config per-host, for hosts that you trust. you should also enable confirmation in ssh-agent so that whenever a key is used, you must manually confirm it. it will prevent attacks like this where another user on a compromised machine will use your agent to login to another machine. i wrote about doing this on osx, but it works similarly on any other platform - http://jcs.org/macssh http://jcs.org/macssh
- forgotusername 15y ago
  Nice approach, modulo the usual problems with dialogs popping up while you're typing (it seems spacebar would confirm that dialog in your post). I no longer use agent forwarding. For config changes I prefer keeping "smarts" close to home and away from production, and in most cases do dumb pushes via rsync/SSH, rather than those machines ever having direct access to revision control, etc.
- dredmorbius 15y ago
  That assumes, say, users not inheriting ~/.ssh/config files, or having one configured for them by a site administrator. Just because a configuration needs to be added to a file doesn't mean that everyone using that config has added it themselves, or understands the implications. Seems that an agent notification of auth requests would help mitigate some of the risks here.

there 15y ago

I'm actually surprised OpenSSH doesn't yet print a large warning when you go to connect and forwarding is enabled. agent forwarding is not enabled by default, so if you've turned it on, you should know what you're doing. it should only be enabled in ~/.ssh/config per-host, for hosts that you trust. you should also enable confirmation in ssh-agent so that whenever a key is used, you must manually confirm it. it will prevent attacks like this where another user on a compromised machine will use your agent to login to another machine. i wrote about doing this on osx, but it works similarly on any other platform - http://jcs.org/macssh http://jcs.org/macssh

forgotusername 15y ago
Nice approach, modulo the usual problems with dialogs popping up while you're typing (it seems spacebar would confirm that dialog in your post). I no longer use agent forwarding. For config changes I prefer keeping "smarts" close to home and away from production, and in most cases do dumb pushes via rsync/SSH, rather than those machines ever having direct access to revision control, etc.
dredmorbius 15y ago
That assumes, say, users not inheriting ~/.ssh/config files, or having one configured for them by a site administrator. Just because a configuration needs to be added to a file doesn't mean that everyone using that config has added it themselves, or understands the implications. Seems that an agent notification of auth requests would help mitigate some of the risks here.