SSH keys serve as a means of identifying yourself to an SSH server using public-key cryptography and challenge-response authentication. One immediate advantange this method has over traditional password authentication is that you can be authenticated by the server without ever having to send your password over the network. Anyone eavesdropping on your connection will not be able to intercept and crack your password because it is never actually transmitted. Additionally, Using SSH keys for authentication virtually eliminates the risk posed by brute-force password attacks by drastically reducing the chances of the attacker correctly guessing the proper credentials.
As well as offering additional security, SSH key authentication can be more convenient than the more traditional password authentication. When used with a program known as an SSH agent, SSH keys can allow you to connect to a server, or multiple servers, without having to remember or enter your password for each system.
SSH keys are not without their drawbacks and may not be appropriate for all environments, but in many circumstances they can offer some strong advantages. A general understanding of how SSH keys work will help you decide how and when to use them to meet your needs. This article assumes you already have a basic understanding of the Secure Shell protocol.
SSH keys always come in pairs, one private and the other public. The private key is known only to you and it should be safely guarded. By contrast, the public key can be shared freely with any SSH server to which you would like to connect.
When an SSH server has your public key on file and sees you requesting a connection, it uses your public key to construct and send you a challenge. This challenge is like a coded message and it must be met with the appropriate response before the server will grant you access. What makes this coded message particularly secure is that it can only be understood by someone with the private key. While the public key can be used to encrypt the message, it cannot be used to decrypt that very same message. Only you, the holder of the private key, will be able to correctly understand the challenge and produce the correct response.
This challenge-response phase happens behind the scenes and is invisible to the user. As long as you hold the private key, which is typically stored in the ~/.ssh/ directory, your SSH client should be able to reply with the appropriate response to the server.
Because private keys are considered sensitive information, they are often stored on disk in an encrypted form. In this case, when the private key is required, a passphrase must first be entered in order to decrypt it. While this might superficially appear the same as entering a login password on the SSH server, it is only used to decrypt the private key on the local system. This passphrase is not, and should not, be transmitted over the network.
Generating an SSH key pair
An SSH key pair can be generated by running the ssh-keygen command:
$ ssh-keygen -t ecdsa -b 521 -C "$(whoami)@$(hostname)-$(date -I)" Generating public/private ecdsa key pair. Enter file in which to save the key (/home/username/.ssh/id_ecdsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/username/.ssh/id_ecdsa. Your public key has been saved in /home/username/.ssh/id_ecdsa.pub. The key fingerprint is: dd:15:ee:24:20:14:11:01:b8:72:a2:0f:99:4c:79:7f username@localhost-2011-12-22 The key's randomart image is: +--[ECDSA 521]---+ | ..oB=. . | | . . . . . | | . . . + | | oo.o . . = | |o+.+. S . . . | |=. . E | | o . | | . | | | +-----------------+
In the above example, ssh-keygen generates a 521 bit long (-b 521) public/private ECDSA (-t ecdsa) key pair with an extended comment including the data (-C "$(whoami)@$(hostname)-$(date -I)"). The randomart image was introduced in OpenSSH 5.1 as an easier means of visually identifying the key fingerprint.
Choosing the type of encryption
The Elliptic Curve Digital Signature Algorithm (ECDSA) provides smaller key sizes and faster operations for equivalent estimated security to the previous methods. It was introduced as the preferred algorithm for authentication in OpenSSH 5.7, see OpenSSH 5.7 Release Notes. ECDSA keys might not be compatible with systems that ship old versions of OpenSSH. Some vendors also disable the required implementations due to potential patent issues.
If you choose to create an RSA (2048-4096 bit) or DSA (1024 bit) key pair instead of ECDSA, use the -t rsa or -t dsa switches in your ssh-keygen command and do not forget to increase the key size. Running ssh-keygen without the -b switch should provide reasonable defaults.
Note|These keys are used only to authenticate you; choosing stronger keys will not increase CPU load when transferring data over SSH.
Choosing the key location and passphrase
Upon issuing the ssh-keygen command, you will be prompted for the desired name and location of your private key. By default, keys are stored in the ~/.ssh/ directory and named according the type of encryption used. You are advised to accept the default name and location in order for later code examples in this article to work properly.
When prompted for a passphrase, choose something that will be hard to guess if you have the security of your private key in mind. A longer, more random password will generally be stronger and harder to crack should it fall into the wrong hands.
It is also possible to create your private key without a passphrase. While this can be convenient, you need to be aware of the associated risks. Without a passphrase, your private key will be stored on disk in an unencrypted form. Anyone who gains access to your private key file will then be able to assume your identity on any SSH server to which you connect using key-based authentication. Furthermore, without a passphrase, you must also trust the root user, as he can bypass file permissions and will be able to access your unencrypted private key file at any time.
Changing the private key's passphrase without changing the key
If the originally chosen SSH key passphrase is undesirable or must be changed, one can use the ssh-keygen command to change the passphrase without changing the actual key.
To change the passphrase for the private RSA key, run the following command:
$ ssh-keygen -f ~/.ssh/id_rsa -p
Copying the public key to the remote server
Once you have generated a key pair, you will need to copy the public key to the remote server so that it will use SSH key authentication. The public key file shares the same name as the private key except that it is appended with a .pub extension. Note that the private key is not shared and remains on the local machine.
If your key file is ~/.ssh/id_rsa.pub you can simply enter the following command.
$ ssh-copy-id remote-server.org
If your username differs on remote machine, be sure to prepend the username followed by @ to the server name.
$ ssh-copy-id email@example.com
If your public key filename is anything other than the default of ~/.ssh/id_rsa.pub you will get an error stating /usr/bin/ssh-copy-id: ERROR: No identities found. In this case, you must explicitly provide the location of the public key.
$ ssh-copy-id -i ~/.ssh/id_ecdsa.pub firstname.lastname@example.org
If the ssh server is listening on a port other than default of 22, be sure to include it within the host argument.
$ ssh-copy-id -i ~/.ssh/id_rsa.pub '-p 221 email@example.com'
By default, for OpenSSH, the public key needs to be concatenated with ~/.ssh/authorized_keys. Begin by copying the public key to the remote server.
$ scp ~/.ssh/id_ecdsa.pub firstname.lastname@example.org:
The above example copies the public key (id_ecdsa.pub) to your home directory on the remote server via scp. Do not forget to include the : at the end of the server address. Also note that the name of your public key may differ from the example given.
On the remote server, you will need to create the ~/.ssh directory if it does not yet exist and append your public key to the authorized_keys file.
$ ssh email@example.com firstname.lastname@example.org's password: $ mkdir ~/.ssh $ cat ~/id_ecdsa.pub >> ~/.ssh/authorized_keys $ rm ~/id_ecdsa.pub $ chmod 600 ~/.ssh/authorized_keys
The last two commands remove the public key file from the server and set the permissions on the authorized_keys file such that it is only readable and writable by you, the owner.