In SSH authentication and encryption are based on the asymmetrical system of public and private keys. Encryption and decryption are performed using different keys. Thereby it is not possible to derive the key for decryption from that used for encryption. For this purpose the user generates a key pair consisting of one public and one private key. The public key is intended for forwarding to other users, whereas the private key is not forwarded by the user.
The two keys are used as follows:
Authentication
When a user logs in on a remote system, this system generates a random number, encrypts it using the user’s public key and returns it to the local system. The appropriate private key is required to decrypt this coded random number; the decrypted date is now sent back to the remote system, where it is checked, thereby the owner of this private key authenticates himself/herself.
The private key enables signatures to be generated (e.g. for a digital signature). A signature generated with a private key cannot be copied by anyone who does not have this key.
Everybody who has the associated public key can verify whether a signature is genuine.
Encryption
The public key can also be used to encrypt a message to someone who has the associated private key.
Only someone who has the associated private key can decrypt such a message.
As the public key is only used to encrypt a message, not too much care must be taken to ensure that it does not fall into the wrong hands (in contrast to the private key).
Generating the keys
Various algorithms are available for generating such key pairs, the best known being RSA and DSA. Under Linux they are generated by calling the ssh-keygen command (see http://www.openssh.com). Only Version 2 RSA keys can be used. The minimum key length is 512 bits. In general, 1024 bits are considered sufficient. The keys generated are stored in the local file system:
The RSA authentication identity is stored in the $HOME/.ssh/id_rsa file and the public RSA key in the $HOME/.ssh/id_rsa.pub file.
The DSA authentication identity is stored in the $HOME/.ssh/id_dsa file and the public DSA key in the $HOME/.ssh/id_dsa.pub file.
The key pairs can also be generated using a GUI-based tool. In this context the PuTTY key generator is described in the section "PuTTY with PuTTYgen and Pageant".
Distributing the public keys to communication partners
In the next configuration step the user must enter the public key in the $HOME/.ssh/authorized_keys file on all remote systems with which he/she wishes to communicate. This can be done, for instance, by copying the local identity file for the public key to the remote systems and appending its content to the $HOME/.ssh/authorized_keys file there.
Passphrases
The private key may not fall into the wrong hands. A few separate protection mechanisms are provided in SSH to prevent this. The ssh program issues a warning if the local identity file can be read by anyone other than the owner. A passphrase can be specified when a key pair is generated. This passphrase is used to encrypt and decrypt the private key when writing to or reading from the identity file.
You are recommended to protect the private key with a passphrase.
A passphrase is an extension of the password. It can be a sequence of words, numbers, blanks, punctuation marks and other arbitrary characters. Good passphrases are 10 to 30 characters long and contain a sequence of uppercase and lowercase letters, numbers and non-alphanumeric characters which are not easy to guess.
Unlike a password, a passphrase is not transferred to a remote computer as part of the authentication procedure.
There is no way of recovering a lost passphrase. Once it has been lost, a new key pair must be generated and its public key must be distributed to the communication partners.