SSH password-free login

Introduction

SSH offers the possibility to login without using passwords using shared keys. Not only is this more convenient than using passwords, it is more secure because only encrypted numbers are exchanged to establish the connection. For more details see CERN SSH instructions, SSH info, and SSH with Putty. Here are my version of the instructions. Caveat: Password-free login does not always work properly on computers with AFS file systems (e.g lxplus, umt3int0X) - the login works, but the user does not get AFS tokens, and hence also gets an Xauthentication error. Hence, at this time, I do not recommend using password-free login on machines with AFS filesystems.

Key Generation

Generate RSA keys with this command: $ ssh-keygen

This generates public and private keys (typically called id_rsa.pub and id_rsa). The public key needs to be copied to "external" computers to allow the password-free login (see below). The private key is used in the "base" computer which you login from. The private key must be hidden from other users just like a password. With the private key, others can do password-free login into your accounts.

Be sure to use a passphrase on the private key, as this adds additional protection to the private key.

Key Installation

On the base computer put the public and private keys in directory ~/.ssh. You have to make sure that the .ssh directory is well-protected. Set the protection to only allow only user access to ~/.ssh:

$ chmod 700 ~/.ssh
$ chmod go-rwx ~/.ssh/*

On AFS file systems (e.g. CERN, and UM cluster) the situation is more complicated. AFS uses "access control lists" (ACL) to control file access. On AFS the ACL must permit rl rights for anyuser to allow ssh to access .ssh to negotiate password-free login.

First check what ACL you already have:

$ fs listacl .ssh
Access list for .ssh is
Normal rights:
  system:anyuser l
  diehl rlidwka

To set ACL do this:

$ fs setacl .ssh system:anyuser rl

However, on an AFS system if have your private key in .ssh you need to protect it further. The way to secure it is to put it in a protected directory and make a soft link from .ssh to the other directory. The other directory should be readable only by the user (not anyuser ). At CERN, it is suggested to put you private key in ~/private which is already set up as a protected directory.

To set up the proper ACL for a protected directory DIR, do this:

$ fs setacl DIR diehl rlidwka -clear 

What this does is clear all the ACLs and then re-set them for user diehl. If you only clear, then you clear all ACLs so that even the user cannot access the directory (or reset the ACLs!). If you do this, you need root privileges to change the ACLs.

On the "external" computer that you want to login into, append your public key to file ~/.ssh/authorized_keys. Set the protections on .ssh as described above.

Password-free login

Now you are set up to do password-free login with ssh, sftp, and scp. When you try to connect you will first have to enter the passphrase for your private key. At first, this may not seem like an advantage over having to use a password, but the section below will tell you how use program ssh-agent to manage your keys, so you only have to enter your passphrase one time.

If you find that the password-free login does not work, connect with ssh -v to get a debugging output on what ssh is doing when it makes a connection.

SSH-Agent

The programs ssh-agent and ssh-add can manage your ssh keys so that you do not have to enter your passphrase every time you want to login. Start ssh-agent as the following (results for tcsh, but of course, one gets analogous results for bash):

$ ssh-agent
setenv SSH_AUTH_SOCK /tmp/ssh-eBgCby7895/agent.7895;
setenv SSH_AGENT_PID 7896;
echo Agent pid 7896;

Here, ssh-agent has started an "agent" process to manage the keys. You must set the environment variables SSH_AUTH_SOCK and SSH_AGENT_PID to use the agent. There are 2 ways to do this:

1. Cut and paste the setenv lines into your terminal.
2. Define an alias in .cshrc: alias sshagent 'eval `ssh-agent \!*`' . Then use command sshagent which will run ssh-agent and automatically set the environment variables.

Next you must load your private key for ssh-agent to use. Do this:

$ cd ~/.ssh
$ ssh-add id_rsa

You will need to enter your passphrase to load the key. However, now you can do any number of password-free logins and never have to enter the passphrase. Use ssh-add -l to list which keys have been loaded.

Ed's SSH-agent helper program

One "feature" of ssh-agent is that every terminal session you run must either start its own agent or set the above environmental variables set to use an existing agent. I have written a utility routine sshagent.pl.txt for this function. The routine is written as a drop-in replacement for ssh-agent. To us this script copy it into say ~/bin, remove the ".txt" extension (added by the twiki), make executable (chmod u+x sshagent.pl), and then define this alias in ~/.cshrc (or equivalent for other shells):

alias sshagent 'eval `~/bin/sshagent.pl \!*`'

Every time you start a terminal run sshagent. It will either start an ssh-agent if there is no one running, or else it will find a running agent and set the environmental variables as needed. It will also list which keys have been loaded and load key ~/.ssh/id_rsa if it finds one (you still need to run ssh-add to load additional keys).

Jim Ree's notes on SSH/AFS

Here are some notes from Jim Rees about how to SSH on AFS systems. These notes are the basis of the information above.

Here's what you want to do:

• use kerberos authentication with ticket passing
• transform the ticket to an afs token on the server side
• move your .Xauthority out of afs, for security and locking reasons
• turn off strict mode checking (afs doesn't use modes)
• move private ssh config files to a world-readable subdir

If the client and server are not in the same keberos realm and not set up for cross-realm you're out of luck. At one time ssh could pass afs tokens but that ability was removed for stupid reasons.

1. Client side (i.e. the user)

a. Put private key in secure subdirectory of .ssh):

fs sa ~/.ssh system:anyuser rl
cd ~/.ssh
mkdir private
fs sa private system:anyuser none

% ls -l
total 3
-rw-r--r--  1 rees  staff   828 Nov 16  2005 authorized_keys
lrwxr-xr-x  1 rees  wheel    14 Jan  1  1999 config -> private/config
-rw-r--r--  1 rees  wheel    31 Jan  1  1999 environment
lrwxr-xr-x  1 rees  wheel    14 Oct 13  2000 id_dsa -> private/id_dsa
-rw-r--r--  1 rees  wheel   604 Oct 13  2000 id_dsa.pub
lrwxr-xr-x  1 rees  wheel    14 Jun 30  2003 id_rsa -> private/id_rsa
-rw-r--r--  1 rees  staff   224 Jun 30  2003 id_rsa.pub
lrwxr-xr-x  1 rees  wheel    19 Mar  7  1997 known_hosts -> private/known_hosts
drwxr-xr-x  2 rees  wheel  2048 Nov  1 15:26 private

b. Put Xauthority file in /tmp for security - do this by setting environment variable XAUTHORITY:

XAUTHORITY=/tmp/Xauthority_put_your_uid_or_uniqname_here

b. file ~/.ssh/config:

Host citi sin dumaguete cadillac (list all your k5/keytab servers here)
ForwardX11 yes
GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes

2. Server side (ie. the computer that you want to ssh to):

a. file sshd_config:

StrictModes no
GSSAPIAuthentication yes
X11Forwarding yes
PermitUserEnvironment yes

b. You also need a keytab on the server. That's a necessary nuisance.

c. One more thing, you have to arrange to run afslog (heimdal) or aklog (MIT) on the server. I do this from my .cshrc. I think there is a pam module that will do this too but I don't use it.

-- EdwardDiehl - 10 Nov 2006