Home > GNU/Linux, Security > Single sign-on: keychain vs pam_ssh

Single sign-on: keychain vs pam_ssh

As an unexpected consequence of the previous post about single sign-on in kdm via pam_ssh I met keychain. It is a nice tool for dealing with both SSH keys and GPG keys. Its main goal is to share a unique ssh-agent between logins. In this post I’ll describe briefly some nice features of keychain and will explain how it can be used for getting single sign-on. As usual, everything shown here has been done on a (testing) Debian box with KDE SC4.

Before starting I assume that your /etc/pam.d/kdm is not using pam_ssh, that OpenSSH is properly installed in your system and you have created a RSA key. In your ~/.bashrc file you have added the line

eval `keychain --nogui id_rsa`

If you restart your X session -so that current ssh-agent and gpg-agent will be killed and new agents will be created during the X session startup sequence- and open a konsole you’ll see something like:

Starting a shell with keychain

The already running agents are, by default, inherited by keychain. Then it uses ssh-add to add the SSH keys specified in the command line to the ssh-agent, and set up the shell environment so that ssh can find the running agent. Because this is the first time we login in this system, the ssh-agent doesn’t know the required SSH keys and we’ll be prompted for a passphrase. If the supplied passphrase is correct then the SSH key will be added to the ssh-agent. If we want to add more identities we can do it via ssh-add command.

Your ~./keychain directory is now populated with the files initialised during the keychain startup (see the above screenshot).

Let’s suppose you start a new konsole (or whatever terminal emulator you like). It doesn’t matter if it is a subshell of the current konsole or not. The .bashrc file will be sourced and keychain executed allowing you to reuse the running ssh-agent so the SSH key added in the first opened shell is available to this new shell too:

Opening a new shell in the X session.

Things get interesting when you want to use ssh in situations in which the environement needed by the ssh-agent (SSH_AUTH_SOCK and SSH_AGENT_PID variables) is not known by the shell. Normally you would need to start new agents. But keychain solves this problem in a clever way: the required environment is described in the files under .keychain and those files can be sourced, exposing the environment to the shell. Let’s see some examples.

You will face the environment problem if you want to run ssh commands in a non interactive shell, for instance in cron jobs. A simple working example of a cron job (assuming that your job is a bash-like script and the the job will be run by the user running the agent) follows:

source /home/vmas/.keychain/rachael-sh
ssh vmas@a_remote_server "ls -l" >> ~/output.txt

As an alternative you can do:

eval `keychain --noask --eval id_rsa` || exit 1
ssh vmas@a_remote_server "ls -l" >> ~/output.txt

Other example. If you connect remotely (for instance via ssh) to your X session you will see something like:

As you can see, the problem is fixed by sourcing the appropriate file.

As a last example, you can login in a virtual console (for instance tty3 via Alt+Ctrl+F3). You will be presented with the usual keychain stuff. However, no identities will be added to the ssh-agent due, one more time, to the environment problem. So the ssh-agent -l command will display the message:

Could not open a connection to your authentication agent.

This problem is fixed again by sourcing the .keychain/${HOSTNAME}-sh.

You can make things easier adding the next lines to your .bashrc, after the line calling keychain. They remove the need of explicitly sourcing files in interactive sessions:

if [ -f "${HOME}/.keychain/${HOSTNAME}-sh" ]; then
. "${HOME}/.keychain/${HOSTNAME}-sh"

Last but not least, keychain can provide you with long term running agents (one of my favorites features). Until now we’ve launched keychain in a way that inherits the agents provided by the X session. It means that if we restart that session the agents will be killed and created again so keychain will use a new pair of agents every time an X session starts. We can force keychain to keep running the agents used the first time it was invoked. In order to do that we change our .bashrc replacing the old keychain invocation with this one:

eval `keychain --nogui --noinherit --stop others id_rsa`

meaning that keychain will not inherit the agents started by the X session (in fact they will be killed). Instead keychain will use its own agents.

In summary, we can say that using keychain we’ll have a unique, long term running, ssh-agent shared between user logins instead of a ssh-agent per login and we’ll be able to use SSH keys in non-interactive sessions too. All the examples above use SSH keys but keychain also supports GPG keys.

Even more, we can use keychain to get single sign-on and a unique ssh-agent shared between logins all at once. Simply add the following lines to your .bashrc:

eval `keychain --nogui --noinherit --stop others id_rsa`
if [ -f "${HOME}/.keychain/${HOSTNAME}-sh" ]; then
. "${HOME}/.keychain/${HOSTNAME}-sh"

This is an interesting combination. Now the very first time that you login in a X session, you will have to authenticate twice: first with your regular password in order to start the session, and then with your passphrase (required by keychain). But from now on every time you restart your X session you will enjoy a nice single sign-on using just your regular password (something I’ve not been able to do with pam_ssh) plus the flexible management of SSH/GPG keys provided by keychain.

Categories: GNU/Linux, Security Tags: , , ,
  1. No comments yet.
  1. November 29, 2010 at 7:21 pm
  2. March 1, 2012 at 7:38 pm
  3. March 17, 2014 at 11:26 pm

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: