Softpanorama (slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-) Softpanorama Search

Private and Public key management

There are two types of keys that are used: server keys and user keys.

When the OpenSSH server package is installed, server authentication keys are generated. They are unique to the server. They are used to verify that the client is connected to the intended server not its imposter.  The first time a client connects to an OpenSSH server, it must accept the server public key. If accepted, the client stores the server public key and uses it to verify the identity of the server with each connection.

User keys mechanism is different. To use public key authentication, the public key of the user has to be stored on the server in the home directory of the user account being accessed. These public keys are stored on the server in the file ~/.ssh/authorized_keys.

The corresponding private key must be stored on the client computer. With the keys stored in the appropriate places, the following occurs

In the public key authentication process:

1. The client informs the server which public key is being used for authentication.
2. The server checks to see if the public key is known.
3. The server encrypts a random number using the public key and  transfers this to the client.
4. Only the client is able to decrypt the random number with its private key.
5. The client sends the server an MD5 checksum that it has  calculated from the number.

Creating a Passphrase

Instead of using a password to authenticate, OpenSSH allows the use of a passphrase. Why use a passphrase? Unlike a password, a passphrase can contain spaces and tabs and is usually much longer than a password, hence the word phrase in the name. The added length along with the spaces and tabs makes a passphrase more secure and harder to guess.

Passphrases are unique per user and must be created by each user while logged in with the corresponding username. Most modern Linuxes uses SSH Protocol 2 and RSA keys by default. To generate an RSA key pair for SSH version 2, use the following command:

ssh-keygen -t rsa

Press Enter to accept the default location of $HOME/.ssh/id_rsa after the key pair is generated. When prompted for a passphrase, type a passphrase to use and type it again to confirm. The passphrase should be different from the user's password and should contain a combination of numbers and letters to make it more secure. Remember it can contain spaces and tabs. The RSA public key is then written to $HOME/.ssh/id_rsa.pub while the private key is written to $HOME/.ssh/id_rsa.

Note:  The private key file should never be accessible by anyone other than the user who created it. It is created with read-write file permissions for the user (600) only. These permissions should never be altered.

After successfully generating the key pair, copy the contents of the public key file $HOME/.ssh/id_rsa.pub to $HOME/.ssh/authorized_keys on all the systems you want to connect to with the SSH.

If the authorized_keys file already exists, append it with the contents of $HOME/.ssh/id_rsa.pub. If the .ssh/ directory does not exist in your home directory on the remote systems, it must be created so that only you, the owner, can access it.

To change the permissions for it, execute the command chmod 0700 $HOME/.ssh on the remote system. The $HOME/.ssh/authorized_keys file on each remote system must have the same permissions as the $HOME/.ssh/id_rsa.pub file created by ssh-keygen.

Change its permissions with the chmod 644 $HOME/.ssh/authorized_keys command on each remote system to which you will be connecting.

After creating an RSA key pair and distributing the public key to the remote systems, when the ssh <hostname> command is executed, the user will be prompted for the passphrase used to create the key pair instead of being prompted for a password for authentication.

Instead of entering the passphrase each time you connect to a remote system, the ssh-agent utility from the openssh-clients package can be used to remember the passphrase.

Additionally, if a graphical desktop is used and the openssh-askpass package is installed, the desktop can be configured to prompt the user for the passphrase after the user logs in to the graphical interface. While that graphical login session is active, the passphrase will be remembered for all terminals opened within that graphical session. To configure ssh-agent as a startup program, use the following steps:

The next time the user logs in to the GUI, a dialog window will appear prompting the user for the passphrase. If the correct passphrase is entered, the user will not have to type the passphrase again when connecting to systems that contain the corresponding $HOME/.ssh/authorized_keys file.

If a graphical interface is not being used, the passphrase can be remembered by executing the following commands:

exec /usr/bin/ssh-agent $SHELL
ssh-add

After you enter the correct passphrase, it will be remembered for that session or terminal window.

Procedure

1. We assume that the user name is the same in both machines.

2. The user keys will be stored in ~/.ssh in both machines.

3. At the client, run 'ssh-keygen -t dsa' to generate a key pair. Accept default options by pressing return. Specially, do not enter any passphrase. (Option -d seems to be an alias of -t dsa in some platforms).

4. Change the permissions of the generated .pub file to 600 by commanding chmod 600 id_dsa.pub

5. Copy the public key to the server with scp id_dsa.pub 'user@server:~/.ssh/authorized_keys'. (Caution: if that destination file already exists on the server, copy first to a different file foo and then append the contents with cat foo >> authorized_keys executed on the server).

6. Done! Verify that now you can connect directly from the client with ssh user@server without being prompted for a password.

7. If it doesn't work, verify that in the server your home directory, the .ssh subdirectory, and the authorized_keys file do not have writing permissions to others. If they do, they won't be considered to grant access. You can correct this with something like:

 chmod 755 ~
 chmod 700 ~/.ssh
 chmod 600 ~/.ssh/authorized_keys

8. If it still doesn't work, try changing the authorized_keys file name to authorized_keys2, or ask your system administrator what file name is ssh actually using.

9. If it worked, you can now run SCP in batch mode with the -B option, as in scp -B foofile 'user@server:~/foodir/'.