Step 4.3 How to Generate a Key Pair Using OpenSSH

Problem: How can a key-pair be created in OpenSSH?

Action 4 3 1 Generating your public private key pair

The ssh-keygen command is utilized to generate your public and private keys. OpenSSH provides authentication methods via a choice of three public key "cryptosystems": RSA1, RSA, and DSA. RSA1 works with SSHv1 while RSA and DSA are for SSHv2. RSA and DSA use different techniques for authenticating and have different capabilities, but for purposes of this guide, either will suffice.

• To create a key-pair, run ssh-keygen with the “t option. The -t option specifies which cryptosystem you want the key to use. The valid options are "rsa", "dsa" or "rsa1". In this example, we have elected to use RSA authentication:

  $ ssh-keygen -t rsa
   Generating public/private rsa key pair
  

• Next you will be prompted for a passphrase, which is used to encrypt the private key. After you enter the passphrase you will be asked to verify it (See Step 4.2 for instructions on how to create a good passphrase.):

  Enter file in which to save the key (/home/sshuser/.ssh/id_rsa):
   Enter passphrase (empty for no passphrase): **********************
   Enter same passphrase again: **********************
  

• If the two passphrases do not match, you will be given an error message and asked to enter the passphrases in again, as shown below.

  Passphrases do not match. Try again.
   Enter passphrase (empty for no passphrase): **********************
   Enter same passphrase again: **********************
  

• Once the passphrases match, ssh-keygen will display a message indicated where the public and private keys will be saved.

  Your identification has been saved in /home/sshuser/.ssh/id_rsa.
   Your public key has been saved in /home/sshuser/.ssh/id_rsa.pub.
   The key fingerprint is:
   9a:7a:87:33:14:d2:12:72:7c:3f:ea:54:a4:2e:b6:ba [e-mail]
  

It is important that you utilize a passphrase you will be able to recall but that would be difficult for someone else to guess. The passphrase is unrecoverable, so if you forget it, you will have to regenerate the public/private keys and a new passphrase.

If you suspect someone may know your passphrase, you should delete your old key pair and create a new one, using a different passphrase. You can also simply change your passphrase on the existing key, but keep in mind this does not help if your key has already been compromised and someone has it in their possession.

To generate a new passphrase on an existing key, use the “p parameter with ssh-keygen :

$ ssh-keygen -p
 Enter file in which the key is (/home/sshuser/.ssh/id_rsa):
 Enter old passphrase: **********************
 Key has comment '/home/sshuser/.ssh/id_rsa'
 Enter new passphrase (empty for no passphrase): **********************
 Enter same passphrase again: **********************
 Your identification has been saved with the new passphrase.

Your newly created public and private key files are stored within your default home directory under the sub-directory named .ssh (the known- hosts file was previously created in this directory when you first attempted a remote SSH connection):

$ cd $HOME
 $cd .ssh
 $ ls -al
 total 10
 drwx------ 2 sshuser 150 512 Feb 11 11:29 .
 drwxr-xr-x 11 sshuser 150 512 Feb 11 10:58 ..
 -rw------- 1 sshuser 150 736 Feb 11 11:29 id_rsa
 -rw-r--r-- 1 sshuser 150 603 Feb 11 11:29 id_rsa.pub
 -rw-r--r-- 1 sshuser 150 458 Dec 20 14:46 known_hosts

There are several other ssh-keygen options “ please refer to the man page, for details:

$ man ssh-keygen
 Reformatting page. Please Wait... done

 User Commands SSH-KEYGEN(1)

 NAME
 ssh-keygen - authentication key generation, management and
 conversion

 SYNOPSIS
 ssh-keygen [-q] [-b bits] -t type [-N new_passphrase] [-C
 comment] [-f output_keyfile]
 ssh-keygen -p [-P old_passphrase] [-N new_passphrase] [-f
 keyfile]
 ssh-keygen -i [-f input_keyfile]
 ssh-keygen -e [-f input_keyfile]
 ssh-keygen -y [-f input_keyfile]
 ssh-keygen -c [-P passphrase] [-C comment] [-f keyfile]
 ssh-keygen -l [-f input_keyfile]
 ssh-keygen -B [-f input_keyfile]
			 ssh-keygen -D reader
 ssh-keygen -U reader [-f input_keyfile]

 DESCRIPTION
 --More--(10%)

It should be noted that you can create and use more than one key-pair.

Action 4 3 2 Configuring remote hosts to authenticate with your public key

Before your initial attempt to connect and authenticate using your key-pair and passphrase, you must configure the remote server to accept this form of communication. This is done by copying the contents of your public key file, $HOME/.ssh/id_rsa.pub (for RSA-style) to the respective authorized_keys file for each account to which you wish to login on the OpenSSH server. If you are using an early version of SSH version 2, the file may be called authorized_keys2 .

For example, if the account "bob" on machine "client1" wants to connect to server "server1" as user "bob" via SSH and wants to be authenticated using a public key, then the public key contents for user "bob" on client1 ( $HOME/.ssh/id_rsa.pub ) will first have to be copied to the $HOME/.ssh/authorized_keys file for account "bob" on server1. If account "bob" on client1 wants to connect as account "ted" via SSH and using public key authentication on server1, then the public key contents must also be added to the HOME/.ssh/authorized_keys file for account "ted" as well.

How do you copy the public key information to the respective authorized_keys file(s)? There are a few methods , depending on whether an authorized_keys file already exists for that account. If you are performing a brand new setup of public key authentication and are sure that no authorized_keys files exists, then you can use any of a number of file copy methods “ the sftp or scp commands documented previously would be recommended. Keep in mind that since you are just now configuring public key authentication, you will be using the UNIX password style of authentication to copy the public key information over. You can also use FTP or rcp, but keep in mind that those commands transfer all information in clear-text.

In the following example, user sshuser on OpenSSH client client.example.com uses sftp to transfer his public key to the authorized_keys file for user sshuser on OpenSSH server server.example.com (in this case, there is no existing authorized_keys file:)

$ pwd
 /home/sshuser/.ssh
 $ ls
 id_dsa id_dsa.pub id_rsa id_rsa.pub known_hosts
 $ sftp server.example.com
 Connecting to server.example.com...
 [e-mail]'s password: *******
 sftp> pwd
 Remote working directory: /home/sshuser
 sftp> cd .ssh
 sftp> put id_rsa.pub authorized_keys
 Uploading id_rsa.pub to /home/sshuser/.ssh/authorized_keys
 sftp> bye

If the authorized_keys file already exists on the server, then you must be careful not to overwrite its contents - otherwise you might affect other OpenSSH clients trying to connect to this account. In this case, you would want to use copy-and-paste functions to append your public key information to the existing authorized_keys file. Be careful when using copy-and-paste functionality that you do not introduce additional line-end characters within the public key “ the public key must be one continuous line. As an alternative to copy-and-paste, the client could sftp the public key file to the OpenSSH server, then login to the server and append this file to the existing authorized_keys file.

For example, let's assume that the authorized_keys file for user sshuser on OpenSSH server server.example.com exists. User sshuser on OpenSSH client client.example.com wishes to add his public key to the existing file. Let's also assume that this information has been sent to the file $HOME/.ssh/id_rsa.pub.copy on server.example.com via sftp. In order to append the new public key information into the existing authorized_keys file we could use the following commands as user sshuser on server server.example.com :

$ cat $HOME/.ssh/id_rsa.pub.copy >>$HOME/.ssh/authorized_keys

Finally, it is extremely important that permissions for the authorized_keys file and its parent directory are set properly - otherwise the OpenSSH server will not honor public key authentication. The files in ~/ .ssh, the .ssh directory, and the home directory must not be writable by any user other than the owner.

$ pwd
 /home/sshuser/.ssh
 $ ls -ld
 drwxr-xr-x 8 sshuser admin 512 Feb 12 17:09 .
 $ ls -l
 total 6
 -rw-r--r-- 1 sshuser admin 446 Feb 12 17:11 authorized_keys
 -rw-r--r-- 1 sshuser admin 688 Dec 20 14:57 known_hosts
 -rw------- 1 sshuser admin 1024 Feb 11 15:26 prng_seed

Action 4 3 3 Using your public key for authentication to a remote server

Once the keys have been generated and your public key has been transferred to each server, you're ready to connect. OpenSSH is designed to detect public key authentication if it has been configured, so all you need to do is issue the appropriate SSH command to be authenticated and connect.

In the following example, OpenSSH client client.example.com is attempting to connect to OpenSSH server server.example.com with slogin . ( slogin is actually just a symbolic link to ssh ):

$ slogin server.example.com
 Enter passphrase for key '/home/sshuser/.ssh/id_rsa': ******************************************************
 Last login: Wed Feb 12 17:09:25 2003 from client.example.com
 $

Notice that instead of a "password" prompt, the user is now prompted for the "passphrase" associated with the public key “ this indicates that the server has recognized a new public key in the authorized_keys file. The server will give priority to the public key authentication before trying the UNIX password authentication method. If you get a "@'s password :" prompt instead of the "passphrase" prompt, then something is not configured correctly. A few things to double-check :

• Compare the user's public key file ( $HOME/.ssh/id_pub.rsa on client) contents with the authorized_keys file on the server ( $HOME/.ssh/authorized_keys ). The public key must be identical in both locations. Make sure the public key is one continuous line with no embedded new-line characters .
• If you are connecting to a different user name on the server, remember to update the correct authorized_keys file. For example, if user "bob" on the client is connecting to user "ted" on the server, then the $HOME/.ssh/id_pub.rsa contents for user "bob" must exist in the authorized_keys for user "ted" on the server ( $HOME/.ssh/authorized_keys ).
• Check the permissions of the authorized_keys file and its parent directory. Remember this file must be writable by the owner only “ any write permissions granted to " group " or "other" will cause the public key authentication to fail.

Once you have the public key authentication configured and working, it will continue to be the first authentication method attempted for any of the OpenSSH client commands: ssh , slogin , sftp , scp , etc. If you forget your passphrase, all is not lost since by default OpenSSH will give you the opportunity to connect via the Unix password if the public key passphrase provided is wrong. For example:

$ ssh server.example.com
 Enter passphrase for key ' /home/sshuser/.ssh/id_rsa': *******************************
 [e-mail]'s password: ********
 Last login: Thu Feb 13 09:45:40 2003 from client.example.com

In this example, an incorrect passphrase was entered, so as the second method of authentication, OpenSSH prompted for the UNIX password. Again, this is the default out-of-the-box behavior for OpenSSH authentication - if you wish to enforce public key style authentication only, the sshd server's default configuration will need to be modified (see Tech Tip on this page). Keep in mind that in order to use the public key authentication again, you'll either need to recall the passphrase or generate new public/private keys and a new passphrase.

Tech Tip  

Of course, allowing a secondary authentication can be considered as defeating the purpose of improved security, so don't be surprised if you are not given the opportunity to connect using a password. If this is the case, the administrator of the OpenSSH server has most likely set "PasswordAuthentication no" in the OpenSSH server's configuration file.

If for some reason you wish to temporarily use another authentication method, each of the SSH connection commands can also be invoked with the "-o" option to temporarily override public key authentication. For example:

$ ssh -o PreferredAuthentications=password server.example.com
 [e-mail]'s password: ********
 Last login: Thu Feb 13 10:42:35 2003 from client.example.com
 $

Action 4 3 4 Removing your public private keys

There is no OpenSSH-specific command for removing your public and private keys. To remove them permanently, use the UNIX rm command. In the following example, the keys generated in Action 4.3.1 are removed:

$ cd $HOME/.ssh
 $ ls -l
 total 6
 -rw------- 1 sshuser 150 951 Apr 10 11:19 id_rsa
 -rw-r--r-- 1 sshuser 150 223 Apr 10 11:19 id_rsa.pub
 -rw-r--r-- 1 sshuser 150 565 Feb 26 10:01 known_hosts
 $ rm ./id_rsa ./id_rsa.pub
 $

If you wish for just a temporary removal / disabling of your keys, then just rename the id files slightly and then change them back to their original names at the appropriate time.

Of course, you will also want to have your public key removed from any authorized_keys files to which it had earlier been added.