During the last three weeks, I have set up Red Hat Enterprise Linux 4 on this server, watched Revolution OS and examined the kernel timeline to find out I must have started with Linux 0.99 in 1993, passed the Red Hat Certified Engineer exam, installed Fedora Core 3 on four machines, and I attend the RH423 course about Directory Services and Authentication this week.

In this course, I came across pam_ssh. When you work on multiple machines and use SSH to connect to them, using a public/private key pair for authentication is a great convenience. You no longer need to remember passwords for the different servers, but only the one for the private SSH key. And there is ssh-agent, which caches the private key, so you do not have to enter the password for every SSH login. Still, you do have to enter the password after login to your local machine.

Now, wouldn't it be cool if you could log in to your desktop machine, and never enter another password until you log out? That's where pam_ssh comes in. It hooks into the login process, asks you for the SSH password instead of your Unix account password, authenticates you and starts ssh-agent.

Configuring it is trivial if you know PAM. The instructions below assume that you use gdm for graphical login, but the process for kdm or xdm should be almost the same.

  1. Save a copy of /etc/pam.d/gdm and make sure that you can log in on a text console before proceeding. Otherwise, you could easily lock yourself out.
  2. Download and install pam_ssh, with the usual ./configure && make install

  3. In /etc/pam.d/gdm, add this line before the line "auth required pam_stack.so service=system-auth":

    auth sufficient pam_ssh.so

    This will make gdm prompt for your SSH private key password, and if it is correct, authenticate you. Otherwise, it will proceed with the usual authentication, ie. ask for your Unix password.

  4. At the end of /etc/pam.d/gdm, add this line:

    session optional pam_ssh.so

    This will set up ssh-agent after you have been authenticated.

  5. On Fedora Core 3, the resulting /etc/pam.d/gdm should look like this:
    auth       required	pam_env.so
    auth	   sufficient   pam_ssh.so
    auth       required	pam_stack.so service=system-auth
    auth       required	pam_nologin.so
    account    required	pam_stack.so service=system-auth
    password   required	pam_stack.so service=system-auth
    session    required	pam_stack.so service=system-auth
    session    optional     pam_console.so
    session	   optional	pam_ssh.so
    

Update 11 Aug 2005: This also works with Fedora Core 4 x86_64, but only after manually installing the pam_ssh module. It is compiled for 64 bit, but installed in the 32 bit lib directory. To fix this, run the following command after make install:

mv /lib/security/pam_ssh.* /lib64/security

Update 14 Apr 2006: Fedora Core 5 comes with pam_ssh as one of the Extras RPMs. You still have to edit /etc/pam.d/gdm, though:

auth       required     pam_env.so
auth       sufficient   pam_ssh.so
auth       include      system-auth
account    required     pam_nologin.so
account    include      system-auth
password   include      system-auth
session    include      system-auth
session    required     pam_loginuid.so
session    optional     pam_console.so
session    optional     pam_ssh.so

Update 26 Nov 2006: When using pam_mount to mount your encrypted home directory during login, put a copy of your SSH key into the unencrypted mount point (usually /home/USERNAME/.ssh). pam_ssh needs to access it before pam_mount does its work. With both pam_mount and pam_ssh, my FC6 /etc/pam.d/gdm looks like this:

auth       required    pam_env.so
auth       required    pam_mount.so
auth       sufficient  pam_ssh.so use_first_pass
auth       include     system-auth
account    required    pam_nologin.so
account    include     system-auth
password   include     system-auth
session    optional    pam_keyinit.so force revoke
session    include     system-auth
session    required    pam_loginuid.so
session    optional    pam_console.so
session    optional    pam_mount.so
session    optional    pam_ssh.so

22:06, 10 Nov 2004 by Carsten Clasohm Permalink

Comments

Security issue

Only problem with pam_ssh is that operations which require the user to re-authenticate (such as changing password, sudo, or sudo-like things such as package managers) can be defeated.  If somebody gets access to a logged in session, it's trivial to replace the ssh key with a new one, and the whole system trusts the new key.

by Anonymous Visitor, 30 Dec 2008

Thank you

I had previously tried to setting this up from the official pam_ssh page, but that borked some daemons which no longer knew who i were, but changing to something like you've got here made it work.

by Anonymous Visitor, 11 Jan 2009

copy of key in unencrypted mount point

Is there any way of getting around having to place a copy of the key in unencrypted mount point?  Wouldn't that be the entire value of an ssh-aware pam_mount?  It would be able to quickly check the key in the encrypted home directory, and either let you log in if it matches and asks for your password/rejects if it doesn't.

by Anonymous Visitor, 22 Jul 2009

Ubuntu?

Any ideas on how to this on Ubuntu?

by Anonymous Visitor, 04 Oct 2009

Not a security issue

@Anonymous Visitor, 30 Dec 2008: That won't work because they would have to know the passphrase and make it the same as the key they're replacing or this module won't allow you to log in and the SSH agent won't be able to add the key.  If they already know your SSH key passphrase then they would just steal your key.

by Anonymous Visitor, 14 Apr 2011

Still a security issue

@Anonymous Visitor, 14 Apr 2011: this is still a security issue. Suppose that someone finds an arbitrary-code-execution exploit for, say, Adobe Flash. Without pam_ssh, they won't be able to change my password and lock me out, because they don't know my old password. With pam_ssh, they just need to rewrite the key to lock me out, they don't need to know the old passphrase.

by Anonymous Visitor, 27 Sep 2011

@Anonymous Visitor

You'd of course not make ssh_pam a PAM password module, i.e. to change your password you still need to know your password. To defy key replacement scenarios one could place all keys on a separate, trusted system and/or account. The first key unlocked by pam_ssh only unlocks the key to this account. Logging in to that account however is read only and the only effect is, that the ssh-agent there adds the private keys stored there. So any attack would only target the intermediary authentication tokens. The tokens on the remote system were safe, as those can not be altered by the single sign on login there.

by Anonymous Visitor, 05 Dec 2011

Add a Comment

Comments are reviewed before they appear on this page.

Title:

Comment:

Text above is