Setting up SSH with RSA Keys

Make sure SSH is running on your remote host

… and make sure RSAAuthentication yes in /etc/ssh/sshd_config. This indicates that the host is capable of accepting RSA keys.

Make sure an SSH client is available on your local system

Execute ‘ssh’ from the command line. If you don’t have ssh, it’s available at http://www.openssh.com/ for *nix. If you’re running windows, you can connect via PuTTY.

Information on setting up PuTTY to use public key encryption is here.

Generate the local key

ssh-keygen -t rsa

This command will by default generate ‘id_rsa’ and ‘id_rsa.pub’ as the private and public RSA key files, and we will refer to them by these names for the rest of this article. You may provide a file name to the program. By default the files get generated in /home/username/.ssh

Passphrase

Make sure you actually use a passphrase here. A properly capitalized and punctuated sentence is good.

Upload the public key to your remote host

Linux users may use the ‘‘ssh-copy-id’’ utility. Alternatively, the following script iterates over your .ssh/config file’s host entries and copies the corresponding key to the remote host automatically.

https://svn.middleware.vt.edu/svn/middleware/users/serac/scripts/network/ssh-key-cp.py

Check directory permissions on your remote host

Both the ‘‘home’’ directory and the ‘‘.ssh’’ directory must not have write permission for group or world.

Since the middleware servers are configured (‘‘/etc/ssh/sshd_config’’) with ‘'’StrictModes yes’’’, these permissions are checked before accepting a login. If either the home directory or the .ssh directory have group and / or world ‘‘write’’ permission, login attempts cause a ‘Permission denied (publickey)’ error.

Note that ‘‘ssh-copy-id’’ does not modify permissions of existing directories or files as claimed in numerous internet articles.

Test your connection

From a separate client window, you should now be able to log in with your passphrase:

ssh username@remote.hostname.com

If you have problems, try running the above command with the -v option to get verbose output.

Using multiple keyfiles

If you wish to use multiple keyfiles, you can map key to host in ‘’~/.ssh/config’’ as shown below. Note this also provides an opportunity to provide convenience aliases for hosts.

# Alias common hosts for convenience
Host apps-dev-1
  HostName apps-dev-1.middleware.vt.edu
  User bob
  IdentityFile /home/bob/.ssh/id_rsa_DEV
Host apps-2
  HostName apps-2.middleware.vt.edu
  User bob
  IdentityFile /home/bob/.ssh/id_rsa_PROD

The above would allow you to authenticate to apps-dev-1.middleware.vt.edu using the following command:

ssh apps-dev-1

You can also use wildcard matching:

Host *dev*.middleware.vt.edu
  IdentityFile /home/bob/.ssh/id_dev_rsa
  User bob
Host *pprd*.middleware.vt.edu
  IdentityFile /home/bob/.ssh/id_pprd_rsa
  User bob

Note that you would have to upload your public keys to the remote host prior to key-based authentication (see above).

Key Caching

Be aware that many operating systems will cache credentials. man ssh-agent on Ubuntu reveals that without specifying the -t option on the command, “the default maximum lifetime is forever.”

In Ubuntu the command that starts up the ssh-agent is the file /etc/X11/Xsession.d/90x11-common_ssh-agent - it is sourced at login-time. Other operating systems will likely use different mechanisms.

to set a timeout for the ssh-agent, set the SSHAGENTARGS value:

SSHAGENTARGS=’-t 1d’ …sets the value to 1 day.

References