Weblog entry #64 for dkg
If you're not using ssh-agent to authenticate yourself to SSH servers, you should be. (i'm assuming you're already using PubkeyAuthentication; if you're still using PasswordAuthentication, ChallengeResponseAuthentication or KbdInteractiveAuthentication, fix that please).
You should use ssh-agent for a number of reasons, actually, but the simplest is this: when you authenticate to a text-based channel on a remote server, you should never have to type anything about that authentication into the channel that will eventually be controlled by the remote server.
That's because a malicious server could simply accept your connection as an anonymous connection and print out the exact prompt you're expecting. Then, whatever you're typing goes into the remote server instead of into your authentication scheme. and congrats, you just gave away the passphrase for your key.
With ssh-agent, you talk first to your agent. Then, you talk to the server and your ssh client talks to the agent. Your keys and your passphrase are never exposed.
the second reason is that the agent is a much smaller piece of code than the ssh client, and it doesn't talk to the network at all (unless you force it to). It holds your key and never releases it to querying processes; It even runs in a protected memory space so other processes can't peek at it.
So if this protected, isolated agent is what holds your key, you're in much better shape than if a non-protected, larger, network-active process (the ssh client) has direct access to your secret key material.
The third reason is that it's just more convenient -- you can put a key in your agent, and ask it to prompt you when its use is requested. you don't actually need to re-type your passphrase each time. you can just hit enter or type "yes".
And if that scares you security-wise then you can put the key in for a limited period of time, as well.
(btw, you should be using the ssh-agent that ships with OpenSSH, probably not the implementation offered by gnome, which doesn't offer a confirmation prompt, doesn't run in protected memory space, and links in a ton more libraries)
So how do you use the agent? It's probably already installed and running on your computer if you run a desktop with debian or another reasonable free operating system.
Query what keys are in your agent:
0 dkg@pip:~$ ssh-add -l The agent has no identities. 1 dkg@pip:~$
Add a standard OpenSSH secret key to your agent, prompting for confirmation before each use:
0 dkg@pip:~$ ssh-add -c ~/.ssh/id_rsa Enter passphrase for /home/dkg/.ssh/id_rsa: your nice long passphrase here Identity added: /home/dkg/.ssh/id_rsa (/home/dkg/.ssh/id_rsa) The user must confirm each use of the key 0 dkg@pip:~$(if you drop the -c, you will not be prompted at each use)
Add a standard OpenSSH secret key to your agent, with a lifespan of one hour (3600 seconds)
0 dkg@pip:~$ ssh-add -t 3600 ~/.ssh/id_rsa Enter passphrase for /home/dkg/.ssh/id_rsa: your nice long passphrase here Identity added: /home/dkg/.ssh/id_rsa (/home/dkg/.ssh/id_rsa) Lifetime set to 3600 seconds 0 dkg@pip:~$(note that you can combine the -t $SECONDS and -c flags to get key that is time-constrained and requires a confirmation prompt at each use)
Add a monkeysphere-style key (an authentication-capable subkey from your GnuPG secret keyring) to the ssh-agent (this will prompt you for your GnuPG passphrase with a graphical ssh-askpass program during this keyload, if such a program is available), for one hour:
0 dkg@pip:~$ monkeysphere subkey-to-ssh-agent -t 3600 Identity added: Daniel Kahn Gillmor <dkg@fifthhorseman.net> (Daniel Kahn Gillmor <dkg@fifthhorseman.net>) Lifetime set to 3600 seconds 0 dkg@pip:~$If you don't already have such a subkey, but you want to use the monkeysphere, you'll need to run monkeysphere gen-subkey to create one first.
Note also that you can use both -c and -t $SECONDS with monkeysphere subkey-to-ssh-agent, just like they are used with ssh-add.
Remove all keys from your running agent:
0 dkg@pip:~$ ssh-add -D All identities removed. 0 dkg@pip:~$
I hope this is helpful to people!
Comments on this Entry
[ Parent | Reply to this comment ]
[ Send Message | View dkg's Scratchpad | View Weblogs ]
Yes. Don't put secret key material available on systems that you don't trust the administrators for.
And don't forward your SSH agent to any system that you don't trust (although confirmation prompting (ssh-add -c) can be a useful protection if you're forced by other circumstances to forward your agent occasionally). However, you don't need to explicitly disable agent forwarding -- you just need to not enable it. ForwardAgent defaults to no in every sensible installation i've ever seen of OpenSSH.
If you find an installation of OpenSSH where ForwardAgent defaults to yes, please file a bug and encourage whoever it is to change that setup.
[ Parent | Reply to this comment ]
[ Send Message | View dkg's Scratchpad | View Weblogs ]
If i was concerned about that, i'd also be concerned about a sysadmin replacing the ssh binary with one that logs secret keys or passwords, or simply reading my secret key out of the memory of the system in the first place.
If your sysadmin is malicious, you're in a whole mess of trouble anyway. Please keep secret key material only on a trusted system.
[ Parent | Reply to this comment ]
Very good advice. I almost never use SSH passwords, keys and a key-agent are so much more convenient.
On my systems I use the PAM-SSH login, which allows login if you can provide a valid SSH key pass-phrase, then loads that into memory (standard ssh-agent) so you don't have to worry about SSH again for the rest of the session.
I'm also the only sudo and the system administrator on the box so if someone else is root then I've got bigger things to worry about...
--
"It's Not Magic, It's Work"
Adam
[ Parent | Reply to this comment ]
[ Send Message | View dkg's Scratchpad | View Weblogs ]
Out of curiosity, do you have the following lines at the end of ~/.ssh/config?
Host * PasswordAuthentication no ChallengeResponseAuthentication no KbdInteractiveAuthentication noIf not, why not?
i want to go look into pam-ssh now. :)
[ Parent | Reply to this comment ]
On my exposed boxes, remote login is by SSH key only, password are very defiantly verboten. However, it's enforced on the server not the client.
pam-ssh is well worth investigating.
--
"It's Not Magic, It's Work"
Adam
[ Parent | Reply to this comment ]
[ Send Message | View dkg's Scratchpad | View Weblogs ]
So i think that enforcing it on the client as well is important. That is, you're effectively saying "i do not expect these servers to prompt for this style of authentication, and i do not want my client to accept them if they do.
[ Parent | Reply to this comment ]
That's because a malicious server could simply accept your connection as an anonymous connection and print out the exact prompt you're expecting. Then, whatever you're typing goes into the remote server instead of into your authentication scheme. and congrats, you just gave away the passphrase for your key.I assume the SSH client does not send cleartext passphrases over the net, does it?
[ Parent | Reply to this comment ]
[ Send Message | View dkg's Scratchpad | View Weblogs ]
But both of those are actually beside the point -- If a compromised or otherwise malicious server uses the "none" authentication mechanism to automatically accept the incoming connection, then it can send whatever text it wants down the pipe as soon as it's established. It doesn't need to send you the shell prompt. It could send you instead this text: Enter passphrase for key '~/.ssh/id_rsa':
If you choose to type your key's password after that, it's just like if you were typing characters into a shell -- the remote computer needs to receive them and process them. At that point, it can save them or relay them wherever.
This isn't a full compromise of your key (because you haven't sent your key down the wire), but it is a full compromise of the passphrase you use for your key. That's a Bad Thing.
[ Parent | Reply to this comment ]
[ Send Message | View dkg's Scratchpad | View Weblogs ]
gconftool-2 --set -t bool /apps/gnome-keyring/daemon-components/ssh falseI think you need to log out and log back in for that settings change to take effect.
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]