SSH Config
Originally published on macresearch.org, around 2007. Reproduced from the author's archive; some links may no longer resolve.
It surprises me sometimes how often I see people typing a password every time they login to a remote system with SSH. For someone working on a cluster or supercomputer, this can be many times a day. Not only that, but it makes it difficult to automate remote commands and scripts when you are not present at the keyboard, such as via launchd or cron. Setting up SSH for password-free access can be a real time saver, but can be a bit confusing, which probably explains why so many don’t bother. So here is the quick tour of password-free SSH configuration.
Option 1: No Passphrase
The easiest option to getting password free access is to use the RSA2 protocol, and not enter a passphrase when creating your SSH keys. (Don’t confuse the passphrase with your account password — they are two separate entities.) You can enter a passphrase for each set of SSH keys you generate; it can be longer than a password, and can include spaces. But if you create a set of keys without any passphrase, you will be able to login without typing a password or passphrase.
First create the keys
ssh-keygen -t rsa
This will prompt you for where you want to keep the key files. You can just use the default by pressing enter.
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/drew/.ssh/id_rsa):
Created directory '/Users/drew/.ssh'.
You will then be asked for a passphrase. Just press enter, and press enter again when reprompted.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /Users/drew/.ssh/id_rsa.
Your public key has been saved in /Users/drew/.ssh/id_rsa.pub.
Now we need to tell SSH that the key just created is authorized for access. To do this, add the ~/.ssh/id_rsa.pub content to the ~/.ssh/authorized_keys file. If the file doesn’t yet exist, you can simply copy the id_rsa.pub file:
cp ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys
Now we need to copy all of these files to the remote machine.
scp -r ~/.ssh username@remote.host.com:
You should see the following
The authenticity of host 'remote.host.com (10.0.0.10)' can't be established.
RSA key fingerprint is 0a:3f:10:2c:22:18:03:93:0a:58:ee:cc:2c:d9:e5:7f.
Are you sure you want to continue connecting (yes/no)? yes
Enter yes at the prompt, and then enter your remote account password when prompted.
That’s it. You should now be able to login to the remote machine without a password.
ssh username@remote.host.com
You may be thinking that not having a passphrase is a security risk. Yes and no. Yes, it isn’t as secure as having a passphrase, but it is still very secure, because for anyone to login to your remote account, they need to have your private key, and to get that, they need to be logged into your account. If they are logged into your account, you have a serious problem anyway.
Option 2: Command-line SSH Agent
If you just can’t bring yourself to have an empty passphrase, there is another option available to you: an SSH agent. In this case, create the keys as above, but enter a passphrase. Once you have a set of keys, start up an SSH agent:
ssh-agent
You should see output like this
SSH_AUTH_SOCK=/tmp/ssh-IOCUDuxaPz/agent.2564; export SSH_AUTH_SOCK;
SSH_AGENT_PID=2565; export SSH_AGENT_PID;
echo Agent pid 2565;
These are commands that you can use in your shell to set the environment up so that the agent is used. Because you probably want to execute these immediately after starting the agent, you could use this command to start the agent instead:
eval `ssh-agent`
That will evaluate the output of the command, setting up the environment as appropriate.
You now need to add your keys to the agent. To do this, use ssh-add
ssh-add
This will prompt you for any passphrases you are using. When you are finished, you should be able to login to the remote machine from the shell without typing a password or passphrase.
There is one serious drawback to this: the agent only works for programs that have their environment configured properly. Each new shell will need to be configured with the environment variables that were printed by the ssh-agent command. You can do some tricky stuff in your resource scripts to do this. For example, when starting the SSH agent, you could dump the output to a file:
ssh-agent > ~/.ssh-agent_config
And then, in your shell resource script (eg .bashrc), you can source this file:
source ~/.ssh-agent_config
This should work for your shells, but it won’t help you much for using password-free SSH in applications like Xcode. For that, you will need…
Option 3: SSH Agent Applications
Probably the best way to use SSH agent is to use it via an application like SSH Agent (link no longer available). Such applications start up the SSH agent for you, and set environment variables at login such that all applications have access to the agent. You can then use SSH with Xcode, for example, to update code from a Subversion repository.
There are several applications that do this. A quick search of VersionTracker (link no longer available) reveals a number of different candidates, and I recommend you try them out and see which fits your needs best. They all do basically the same thing: at login, environment variables are set so that SSH knows to query the application for passphrases. The application adds your SSH keys to the agent when it is launched (like ssh-add), and then supplies SSH with passphrases when requested.
Conclusions
That’s it in a nutshell. Option 3 is probably the most robust, and is not too difficult. If you are very lazy, you could get away with Option 1. The only option I recommend against is Option 0, because typing your password every time you login is a frightful waste of time and energy, and limits your possibilities in regard to remote automation.