SSH: The Secure Shell (The Definitive Guide)
Barrett, Silverman, & Byrnes / O’Reilly
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 UseFor 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 -lIf 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
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 SSHYour main choices of authentication method for unattended SSH operation are, in order of increasing security:
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
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.