Weblog entry #64 for dkg

You should be using ssh-agent
Posted by dkg on Mon 27 Sep 2010 at 20:18

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

Posted by Anonymous (82.238.xx.xx) on Mon 27 Sep 2010 at 23:33
Aren't you concerned with a sysadmin impersonating you and reusing your agent, by setting the proper environnement variables after doing a su ?

[ Parent | Reply to this comment ]

Posted by Anonymous (195.93.xx.xx) on Tue 28 Sep 2010 at 10:40
I'm assuming he is considering the system you run the agent on as a trusted system. Also, if you don't trust the remote system, you _must_ disable agent forwarding.

[ Parent | Reply to this comment ]

Posted by dkg (216.254.xx.xx) on Tue 28 Sep 2010 at 18:35
[ 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 ]

Posted by dkg (216.254.xx.xx) on Tue 28 Sep 2010 at 18:40
[ 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 ]

Posted by ajt (195.145.xx.xx) on Wed 29 Sep 2010 at 13:18
[ Send Message | View Weblogs ]

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 ]

Posted by dkg (216.254.xx.xx) on Wed 29 Sep 2010 at 17:39
[ Send Message | View dkg's Scratchpad | View Weblogs ]
Thanks for the kind words!

Out of curiosity, do you have the following lines at the end of ~/.ssh/config?

Host *
PasswordAuthentication no
ChallengeResponseAuthentication no
KbdInteractiveAuthentication no
If not, why not?

i want to go look into pam-ssh now. :)

[ Parent | Reply to this comment ]

Posted by ajt (195.112.xx.xx) on Wed 29 Sep 2010 at 21:20
[ Send Message | View Weblogs ]

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 ]

Posted by dkg (216.254.xx.xx) on Wed 29 Sep 2010 at 21:39
[ Send Message | View dkg's Scratchpad | View Weblogs ]
I agree with your having enforced it on the server. But if one of your servers is ever compromised, its configuration could change and a hostile sshd could send password requests (or faked key-unlock prompts via KbdInteractiveAuthentication, etc).

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 ]

Posted by Anonymous (212.110.xx.xx) on Wed 23 Apr 2014 at 19:22
> 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.

This sounds like security through ostrich. Frankly, if my server sends me password prompt when it isn't supposed to, I want to see it loud and clear.

Now on another note, what's wrong with password authentication? Don't get me wrong, keybased authentication has a few advantages, but as far as I can tell they're more a matter of convenience than security.

[ Parent | Reply to this comment ]

Posted by mcortese (20.142.xx.xx) on Thu 30 Sep 2010 at 10:11
[ Send Message | View Weblogs ]
I'm not sure I understand this part:
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 ]

Posted by dkg (216.254.xx.xx) on Thu 30 Sep 2010 at 23:21
[ Send Message | View dkg's Scratchpad | View Weblogs ]
Actually, the password authentication mechanism for ssh suggests that it can send cleartext passwords to the remote server (albeit within an encrypted tunnel so other entities can't snoop), and the KbdInteractiveAuthentication is another scheme that sends what you type directly down the wire.

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 ]

Posted by dkg (2001:0xx:0xx:0xxx:0xxx:0xxx:xx) on Tue 7 Dec 2010 at 20:38
[ Send Message | View dkg's Scratchpad | View Weblogs ]
Note: if you're using the ssh-agent features from the gnome keyring, and you don't want to (because, as noted above, the gnome-keyring doesn't support confirmation prompts), you can disable ssh support in GNOME keyring. This appears to also be doable from the command line with:
gconftool-2 --set -t bool /apps/gnome-keyring/daemon-components/ssh false
I think you need to log out and log back in for that settings change to take effect.

[ Parent | Reply to this comment ]