SSH Agent
Typing passphrases every time you need to connect to a server is a real hassle. Woudn’t it be nice if there was a service that does that for you? In fact there is, and its called SSH Agent !
Manual Use of SSH Agent
ssh-agent works with the ssh-add which adds keys to the agent. Here is an example:
[joe@local.acme]: eval "$(ssh-agent -s)" # Start the agent service
[joe@local.acme]: ssh-add ~/.ssh/id_ed25519 # Add the key to agent
Enter passphrase for ~/.ssh/id_ed25519: ********
Identity added: ~/.ssh/id_ed25519 (~/.ssh/id_ed25519)
Identity added: ~/.ssh/identity (joe@local.acme)
[joe@local.acme]: ssh remote.acme # remote ssh wont require passphrase now
[joe@server.acme]:
You could automate ssh-agent startup in your .profile file:
SSHAGENT=/usr/bin/ssh-agent
SSHAGENTARGS="-s"
if [ -z "$SSH_AUTH_SOCK" -a -x "$SSHAGENT" ]; then
eval `$SSHAGENT $SSHAGENTARGS`
trap "kill $SSH_AGENT_PID" 0
fi
To cleanup when you logout, you kill the agent in .logout:
SSH_AGENT_PID="$(pidof ssh-agent)" ssh-agent -k
This all seems ok, but its a bit messy. There is a simpler way to get all this working, keychain, and we talk about it next.
\(\pagebreak\)
Using Keychain
What we did before with ssh-agent is better, but it suffers from several afflictions. First, it is confined to the shell we were using, so we would have to start it in each shell. Secondly, ssh-agent won’t work with cron jobs since cron doesn’t inherit your environment, and won’t let you type in passphrases. Cron is too important to ignor, especially for admins.
The fine makers of Gentoo Linux have created a program that allows you global access to ssh-agent information. The program is called keychain, and it asks you for your passphrase one time only and can then use it in every shell you start afterwards. Thus, you only have to type in your passphrase one time per login and also eliminates multiple copies of ssh-agent from running concurrently.
To use keychain, you must first invoke it with your private keys as arguements:
[joe@local.acme]: keychain ~/.ssh/id_ed25519
KeyChain 2.0.2; http://www.gentoo.org/projects/keychain
Copyright 2002 Gentoo Technologies, Inc.; Distributed under the GPL
+ Found existing ssh-agent at PID 26744
+ 1 more keys to add...
Enter passphrase for .ssh/id_ed25519: *************
Identity added: .ssh/id_ed25519 (.ssh/id_ed25519)
What Keychain did is to write the environment variables needed for authentication (via ssh-agent) in ~/.keychain/$HOSTNAME-sh if you use bash and ~/.keychain/$HOSTNAME-csh if you use tcsh.
This is what you see when you list the directory:
[joe@local.acme]: ls -l .keychain
total 8
-rw------- 1 joe joe 80 Apr 29 23:29 local.acme-csh
-rw------- 1 joe joe 110 Apr 29 23:29 local.acme-sh
Now all you have to do is put 2 lines into your startup scripts, and enter your passphrase one time! Here is a sample ~/.bash_profile that has keychain enabled:
#! /bin/bash
# First invoke keychain on your private keys:
/usr/bin/keychain ~/.ssh/id_rsa ~/.ssh/id_ed25519
# Next, source the files that keychain created:
source ~/.keychain/$HOSTNAME-sh
.... other stuff ....
Here is the similar lines for tcsh:
#! /bin/tcsh
/usr/bin/keychain ~/.ssh/id_rsa ~/.ssh/id_ed25519
# Next, source the files that keychain created:
source ~/.keychain/$HOSTNAME-csh
.... other stuff ....
Exercises
Install and setup keychain for your account.
Test keychain by logging out and back in. Can you ssh to server.acme now without entering a passphrase? If not, something went wrong above.
Add keychain support to your fetchmail script above and test it (See below):
#! /bin/bash source ~/.keychain/$HOSTNAME-sh > /dev/null /usr/bin/fetchmail -v
Agent Forwarding
One security flaw with SSH agent is that if an intruder gets root access on the system, your decrypted keys can be gotten from ssh-agent. This will compromise your network.
One way to avoid this is to only use ssh-agent from trusted (secure) hosts via SSH Agent Forwarding. Agent forwarding works by allowing remote ssh sessions to contact ssh-agent running on a secure host. You implement this by changing a line in local.acme’s /etc/ssh/ssh_config file:
ForwardAgent Yes
Assume we have 3 machines: local.acme server.acme and untrusted.acme. We want to first ssh to server.acme, and then ssh into untrusted.acme without entering passphrases. For this to work correctly, your public key from local.acme must be on server.acme and on untrusted.acme:
SSH Agent Forwarding
Since untrusted.acme is insecure, we don’t want to expose our keys to it ever, nor expose our ssh-agent to it. This accomplishes that goal. We test our system by ssh’ing to server.acme, then to untrusted.acme, making sure no passphrase or passwords are asked for:
[joe@local.acme]: ssh server.acme
Welcome to server.acme!
Last login: Fri May 2 23:03:23 2003 from 192.168.1.9
[joe@server.acme]: ssh untrusted.acme
Welcome to untrusted.acme!
Last login: Fri May 2 22:09:39 2003 from 192.168.1.20
If you have to enter any passwords or passphrases, we have a problem.
Exercises
Make sure your Agent Forwarding works as described. Work with your peers and their admins to make sure they have the right settings.
Discuss scenarios that use Agent Forwarding to secure your network at work or home.
Draw a diagram of your proposed network with Agent Forwarding indicated.
Dangers of Agent Forwarding
Agent Forwarding is no panacea. It has several drawbacks from a security point of view. The following is paraphrased from the September 25, 1999 man page of ssh (1):
-A Enables forwarding of the authentication agent connection.
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.
As with any technology, it must be used with respect and caution.