It can be useful to configure the ssh client and server to make use of a cryptographic asymmetric key pair rather than a text password for various reasons, including:
- Logins can be automated, which saves time and eliminates the headaches of remembering lengthy passwords.
- Text passwords can be eliminated entirely, which can improve the security of machines that are accessible by non-trustworthy clients (e.g., Internet bad guys), if you happen to be using a weak password or one that might be guessed.
This article is a brief summary on how to configure automated access and should be sufficient for automating logins on a local network. However, additional care and research should be expended if configuring this capability across the Internet / publicly accessible machines. In this case, your first and best resource will be the man pages for the commands and configuration files referenced below.
If you're not familiar with asymmetric cryptography ( public / private keys ), a great reference is a book by Christof Parr: "Understanding Cryptography". It's well written, comprehensive, and relatively inexpensive. Also, he offers an entire companion two semester college course online for free - see his site or youtube.
Generating a public / private key pair
The first thing we need to do is generate a pair of keys: public and private. The private key will remain hidden on the client, and the public key will be copied to each remote server that we wish to access automatically and securely. If the private key is ever suspected of being compromised or revealed, then both keys should be deleted and regenerated
The following transcript is from a terminal window on Mac OS El Capitan (Version 10.11). The user name is "tony" and the keys will be stored in the default .ssh directory in the user's home directory.
$ ssh-keygen Generating public/private rsa key pair. Enter file in which to save the key (/Users/tony/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /Users/tony/.ssh/id_rsa. Your public key has been saved in /Users/tony/.ssh/id_rsa.pub. The key fingerprint is: SHA256:Gcr+WDlev6fopWmh643m/iGOW8ZHGcp89WFkJr5fEhk tony@mac The key's randomart image is: +---[RSA 2048]----+ | . E | | . = o | | . . o = | | . + + + + o | | o S + . o .| | . . +. . o | | . O.+.. . | | XoB.B . | | +*X=B ++ | +----[SHA256]-----+
The randomart image is a representation of the key that you may or may not want to recall. If you add VisualHostKey=yes to your .ssh/config file, then you'll see a unique image each time you log into a particular remote machine. This could help guard against trusting a compromised remote machine that had been swapped out and always accepts your login in an attempt to gain additional information. This is similar to what some banks and brokerage houses deploy, which require you to recognize an image as a safeguard.
Since we're using Mac OS X, El Capitan, let's take a brief detour and double check which ssh-keygen tool we just used.
which ssh-keygen | xargs ls -l -rwxr-xr-x 1 root wheel 1434352 Sep 17 03:07 /usr/bin/ssh-keygen $ sudo rm /usr/bin/ssh-keygen override rwxr-xr-x root/wheel restricted,compressed for /usr/bin/ssh-keygen? y rm: /usr/bin/ssh-keygen: Operation not permitted
Well, we see that we're using the ssh-keygen tool shipped with Mac OS. Since it's El Capitan or later and we haven't disabled SIP ( System Integrity Protection ), we can't delete executables in /usr/bin. Is Apple being too controlling?
Back to the key pairs: We generated two files in our .ssh directory
- id_rsa.pub: public key
- id_rsa: private key
From "man ssh-keygen": the id_rsa file contains "the protocol version 2 DSA, ECDSA, ED25519 or RSA authentication identity of the user. This file should not be readable by anyone but the user. It is possible to specify a passphrase when generating the key; that passphrase will be used to encrypt the private part of this file using 128-bit AES.... ssh will read this file when a login attempt is made."
The id_rsa.pub file contains "the protocol version 2 DSA, ECDSA, ED25519 or RSA public key for authentication. The contents of this file should be added to ~/.ssh/authorized_keys on all machines where the user wishes to log in using public key authentication. There is no need to keep the contents of this file secret."
If we had generated our key pair on a Linux machine, ssh-copy-id would be available as a convenience to copy our public key to a remote machine. As it is, we'll just manually fix it up by doing the following:
- Open id_rsa.pub and copy the text. If you're not familiar with editors inside your terminal, vi is usually available.
- Login to the remote machine ( using ssh the old way ). Open .ssh/authorized_keys and paste the public key line that you just copied into the end of the file.
- Exit and try to log back in via ssh. You should be able to do it without typing a password.
If you had been using Linux all along, your life would be even easier by using ssh-copy-id as shown below. Working now from a Linux machine:
$ ssh-copy-id -i .ssh/id_rsa.pub mac Are you sure you want to continue connecting (yes/no)? yes /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys Password: Number of key(s) added: 1 Now try logging into the machine, with: "ssh 'mac'" and check to make sure that only the key(s) you wanted were added. $ ssh mac Last login: Fri Oct 23 16:33:25 2015 $
Note that "mac" is the name of the remote machine just configured for automated login via ssh. You may also see some text during the process indicating that the machine was not recognized. This is probably to be expected. However, please read everything carefully.
The other thing to consider once the automated login is working is whether you want to disable password logins. This can be done by modifying the /etc/ssh/sshd_config file. Check your man pages on the relevant settings and only do this if you are able to get in front of the machine to login directly in case you break ssh remote login.
If the above instructions for automated login didn't work, check the config file on the remote sever: /etc/ssh/sshd_config. It should have the following lines set:
RSAAuthentication yes PubkeyAuthentication yes
Lastly, if you're having problems, consider looking at the logs. If you edit your /etc/ssh/sshd_config file, you should see a couple lines under Logging:
# Logging SyslogFacility AUTH LogLevel DEBUG
Our file has already been modified to send debugging information to the logs. On Linux, I can find the log information in auth.log, which on Ubuntu and Mac OS is under /var/log