SSH Frequently Asked Questions

How do I arrange to log in without typing a password or passphrase?

There are two different reasons for wanting to do this: single sign-on in an interactive context, versus using SSH for unattended processes (e.g. cron or batch jobs).

Interactive Use

For automatic authentication in an interactive context, you should use public-key authentication with ssh-agent, hostbased authentication, or Kerberos if available. To use ssh-agent, first get public-key authentication working without it, so that SSH works but you must enter your key passphrase each time you connect. Then simply type:

  % eval `ssh-agent`
  % ssh-add <private key file> # e.g. ~/.ssh/id_RSA
  % ssh-add -l

If all goes well, the last command should list the key you've added to the key agent, and your SSH commands in this shell have access to your key without further intervention from you. [ssh-agent]

Regarding Plaintext (= unencrypted = "no-passphrase") Keys

DON'T USE THEM.

It is very common to see people giving out advice like this: "Oh, automatic login with SSH is easy — just get rid of that pesky passphrase! Type when ssh-keygen prompts for a passphrase, and voil�!"

This will indeed work. However, it is equivalent to placing your account password in a file in your home directory named PLEASE-STEAL-MY-PASSWORD.TXT, doing chmod 600, and feeling very secure. Anyone who gains access to this account now has automatic access to any of your other accounts using that key. Your key could be stolen off a single backup tape from this system, or via insecure file-sharing protocols such as SMB or NFS, if your home directory is shared using them. There is no reason to use a plaintext key for interactive SSH, since ssh-agent provides the same benefits in a much more secure manner.

If you're using an SSH package which does not provide an agent or equivalent feature, think hard about the vulnerability before resorting to plaintext keys. Also think hard about using a different SSH package.

Unattended SSH

Your main choices of authentication method for unattended SSH operation are, in order of increasing security:

hostbased (= SSH-1 "RhostsRSA")
public-key with plaintext key file (i.e. no passphrase)
public-key with ssh-agent

Hostbased is the most convenient, but may not be available or appropriate for your situation; it's the least secure option. Among other things, the authorization restrictions available via the .shosts and hosts.equiv files are limited, and easy to get wrong. This is not to say it can't ever be the right choice; you just have to know what you're doing.

Some flavor of public-key is better. In order for SSH to work unattended with public-key authentication, the keys must exist in plaintext somewhere; it's just a question of where. Your choices are in an agent, or in a file (an unencrypted, no-passphrase key file).

The agent affords the greatest security, since the key does not exist in plaintext on disk anywhere. Also, it's a little more difficult for an intruder to extract the keys from the memory image of the running agent than to just gain illicit access to a plaintext key file. But it's cumbersome, since someone must start the agent and load the key, and you must arrange for your batch jobs to find the agent. And if your system reboots, it requires human intervention to reload the keys, making it inappropriate for some uses where automatic system recovery is needed. If you find yourself trying to think of ways to automatically load the keys into the agent, then you don't really want to use the agent. For instance, if you scripted the use of ssh-add, you would have to include the key passphrases in the script. Since having the keys and their passphrases sitting around on disk is essentially equivalent to having a plaintext key, you may as well do that and save yourself some trouble.

If you use a plaintext key, make sure it resides on a local disk and does not traverse the network via NFS. You may also want to ensure that it does not get backed up, since then making off with one of your backup tapes is an easy way to break in. In either case with public-key, use the available authorization restrictions (e.g. options in the authorized_keys file) to limit the keyholder to performing only the needed tasks, from the correct machines.

Do not try to use password authentication by feeding SSH a password from a script. It will be difficult, because SSH requires a pty from which to read the password. It's made difficult on purpose, because you shouldn't do it. It's essentially equivalent to using a plaintext key, but without the advantage of being able to restrict the login using key options.

Do not employ a plaintext key for interactive use! There is no reason to do it; ssh-agent provides the same benefits in much more secure manner.

The statements about relative security are only guidelines, of course; your circumstances will dictate which is the right trade-off.