Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I was reading SSH tips and tricks from http://blogs.perl.org/users/smylers/2011/08/ssh-productivity-tips.html
There is a section on Onward Connections and the author warns not to use this unless you trust sys-admins on the middle servers.

I wanted to know what are the security implications of enabling Onward connections for SSH.

share|improve this question
add comment

1 Answer

up vote 4 down vote accepted

There is no security problem with SSH agent forwarding per se; that is, there is no additional risk that you would not see by manually logging in to the remote server and connecting to a third machine.

The risk lies in the fact that a malicious system owner (or attacker, if the system has already been compromised) is in a perfect position for a man-in-the-middle attack.

The MitM attack could come from several different vectors, although two come to mind specifically. The malicious admin could attempt to sslstrip an outgoing SSH connection so that your data (including credentials) is readable in transit, or he could change DNS so that you are connecting to an SSHd designed specifically to steal passwords, rather than the destination you were initially trying to reach.

Again, though, these risks would be present while using a third-party server even without specifically using SSH agent forwarding.

Hope this helps :)

share|improve this answer
SSLstrip? I don't understand the attack you have in mind. I don't understand why there is even any question of stripping; if the data is exposed in the clear to the middle server, then nothing needs to be stripped: the middle server can already see it, without needing to do anything fancy. In other words, I don't understand an active man-in-the-middle attack. Perhaps you're just talking about simple eavesdropping/data capture? –  D.W. Nov 29 '11 at 22:11
D.W., I am talking about using the middle server as a bounce point for encrypted communication. For example, scp Middle.Host:~/remote.file Third.Host:~/. In this case, the communication is entirely encrypted, but a MitM attack could occur from Middle.Host to Third.Host. If the data is already in plaintext, that is even easier! –  dshaw Nov 29 '11 at 22:48
dshaw, now I'm really confused. I can't follow your exposition at all. In your example scp command, I don't see any opportunity for MitM attacks. In fact, there's not even any agent forwarding in this scenario, if you are doing the scp from your local machine. Care to clarify your example and your answer? –  D.W. Nov 30 '11 at 6:25
I thought the risk is that if I have my public key on unrelatedserver.com, and I ssh in to publicserver.com, root@publicserver.com could ssh in to unrelatedserver.com and have the agent running on my local machine authenticate them. I could be wrong though-- I just came here to look this up myself since I always avoided it for that reason. –  semi Apr 8 at 16:21
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.