SSH Agent

Typing passphrases every time you need to connect to a server is a real hassle. Maybe there is a service that does that for you? The SSH Agent does this!

Manual Use of SSH Agent

Well there is such a service; its called ssh-agent, and it works with the ssh-add which adds keys to the agent. Here is an example:

[joe@local.acme]: ssh-agent /bin/bash
[joe@local.acme]: ssh-add
 Enter passphrase for /home/joe/.ssh/id_ed25519: ********
 Identity added: /home/joe/.ssh/id_ed25519 (/home/joe/.ssh/id_ed25519)
 Identity added: /home/joe/.ssh/identity (joe@local.marx)
[joe@local.acme]: ssh remote.marx
[joe@server.acme]:

Using Keychain to Manage SSH Agent

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.marx-csh
-rw-------    1 joe joe      110 Apr 29 23:29 local.marx-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.marx 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.marx’s /etc/ssh/ssh_config file:

ForwardAgent Yes

Assume we have 3 machines: local.marx server.marx and untrusted.marx. We want to first ssh to server.marx, and then ssh into untrusted.marx without entering passphrases. For this to work correctly, your public key from local.marx must be on server.marx and on untrusted.marx:

.. figure:: images/agentforwarding

   SSH Agent Forwarding

Since untrusted.marx 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.marx, then to untrusted.marx, making sure no passphrase or passwords are asked for.

[joe@local.acme]: ssh server.marx: Welcome to server.marx! Last login: Fri May 2 23:03:23 2003 from 192.168.1.9
[joe@server.acme]: ssh untrusted.marx: Welcome to untrusted.marx! 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.