Using SSH Without a Password in bash

You need to use SSH or scp in a script and would like to do so without using a password.
Or you’re using them in a cron job and can’t have a password.*

There are two ways to use SSH without a password, the wrong way and the right
way.

The wrong way is to use a public-key that is not encrypted by a passphrase.

The right way is to use a passphrase protected public-key with ssh-agent or keychain.
We assume you are using OpenSSH; if not, consult your documentation (the commands and files will be similar).

First, you need to create a key pair if you don’t already have one.

Only one key pair is necessary to authenticate you to as many machines as you configure, but you may decide to use more than one key pair, perhaps for personal and work reasons.

The pair consists of a private key that you should protect at all costs, and a public key (*.pub) that you can post on a billboard if you like.

The two are related in a complex mathematical way such that they can identify each other, but you can’t derive one from the other.
Use ssh-keygen (might be ssh-keygen2 if you’re not using OpenSSH) to create a key pair. -t is mandatory and its arguments are rsa or dsa. -b is optional and specifies the number of bits in the new key (1024 is the default at the time of this writing) .

-C allows you to specify a comment, but it defaults to user@hostname if you omit it.

We recommend at least using -t dsa -b 2048 and we recommend strongly against using no passphrase.

ssh-keygen also allows you to change your key file’s passphrase or comment.

Once you have a key pair, add your public key to the ~/.ssh/authorized_keys file in your home directory on any other machines to which you wish to connect using this key pair.

You can use scp, cp with a floppy or USB key, or simple cut-and-paste from terminal sessions to do that.

The important part is that it all ends up on a single line.
While you can do it all in one command (e.g., scp id_dsa.pub remote_host:.ssh/
authorized_keys), we don’t recommend that even when you’re “absolutely sure” that authorized_keys doesn’t exist.

Instead, you can use a slightly more complicated but much safer command, shown in bold:

As you can see, we were prompted for a password for the initial scp, but after that ssh just worked.

What isn’t shown above is the use of the ssh-agent, which cached the passphrase to the key so that we didn’t have to type it.
The command above also assumes that ~/.ssh exists on both machines.

If not, create it using mkdir -m 0700 -p ~/.ssh.

Your ~/.ssh directory must be mode 0700 or OpenSSH will complain.

It’s not a bad idea to use chmod 0600 ~/.ssh/authorized_keys as well.

It’s also worth noting that we’ve just set up a one-way relationship.

We can SSH from our local host to our remote host with no password, but the same is not true in reverse, due to both lack of the private key and lack of the agent on the remote host.
You can simply copy your private key all over the place to enable a “web of passwordless SSH,” but that complicates matters when you want to change your passphrase and it makes it harder to secure your private key.

If possible, you are better off having one well protected and trusted machine from which you ssh out to remote hosts as needed.
The SSH agent is clever and subtle in its use. We might argue it’s too clever.

The way it is intended to be used in practice is via an eval and command substitution: eval ssh-agent.

That creates two environment variables so that ssh or scp can find the agent and ask it about your identities.

That’s very slick, and it’s well documented in many places.

The only problem is that this is unlike any other program in common use and
is totally obtuse to a new or uninformed user.
If you just run the agent, it prints out some details and looks like it worked.

And it did, in that it’s now running. But it won’t actually do anything, because the necessary environment variables were never actually set.

We should also mention in passing that the handy -k switch tells the agent to exit.

Intuitive isn’t it? Not. Very slick, very efficient, very subtle, yes. User friendly, not so much.
OK, so once we have the agent running as expected we have to load our identities
using the ssh-add command.

That’s very easy, we just run it, optionally with a list of key files to load.

It will prompt for all the passphrases needed.

In this example we did not list any keys, so it just used the default as set in the main SSH configuration file:

So now we can use SSH interactively, in this particular shell session, to log in to any machine we’ve previously configured, without a password or passphrase.

So what about other sessions, scripts, or cron?
Use Daniel Robbins’ keychain (http://www.gentoo.org/proj/en/keychain/) script, which:

keychain is a clever, well-written and well-commented shell script that automates and manages the otherwise tedious process of exporting variables
we discussed above into other sessions.

It also makes them available to scripts and cron.

But you’re probably saying to yourself, wait a second here, you want me to leave all my keys in this thing forever, until the machine reboots?

Well, yes, but it’s not as bad as it sounds.
First of all, you can always kill it, though that will also prevent scripts or cron from using it.

Second, there is a –clean option that flushes cached keys when you log in.
Sound backward? It actually makes sense.

Here are the details, from keychain’s author (first published by IBM developerWorks at http://www.ibm.com/ developerworks/, seehttp://www.ibm.com/developerworks/linux/library/l-keyc2/):

To actually use the keychain-wrapped ssh-agent from a script or cron, simply source the file keychain creates from your script.

keychain can also handle GPG keys:

When using SSH in a script, you don’t want to be prompted to authenticate or have
extraneous warnings displayed.

The -q option will turn on quiet mode and suppress warnings, while -o ‘BatchMode yes’ will prevent user prompts.

Obviously if there is no way for SSH to authenticate itself, it will fail, since it can’t even fall back to prompting for a password.

But that shouldn’t be a problem since you’ve made it this far in this recipe.
SSH is an amazing, wonderful tool and there is a lot to it, so much that it fills another book about this size.

We highly recommend SSH, The Secure Shell: The Definitive Guide by Richard E. Silverman and Daniel J. Barrett (O’Reilly) and for everything you ever wanted to know (and more) about SSH.
Using public keys between OpenSSH and SSH2 Server from SSH Communications
Security can be tricky; see Chapter 6 in Linux Security Cookbook by Daniel J. Barrett et al. (O’Reilly).
The IBM developerWorks articles on SSH by keychain author (and Gentoo Chief
Architect)

Daniel Robbins are also a great reference (http://www.ibm.com/ developerworks/linux/library/l keyc.htmhttp://www.ibm.com/developerworks/linux/
library/l-keyc2/, http://www.ibm.com/developerworks/linux/library/l-keyc3/).
If keychain doesn’t seem to be working, or if it works for a while then seems to stop,
you may have another script somewhere else re-running ssh-agent and getting things out of sync.

Check the following and make sure the PIDs and socket all agree.

Depending on your operating system, you may have to adjust your ps command; if
-ef doesn’t work, try -eu.