(This is mostly copied from the ssh and ssh-keygen manual pages.)
Public key authenticationPublic key authentication is based on public-key cryptography, using cryptosystems where encryption and decryption are done using separate keys, and it is unfeasible to derive the decryption key from the encryption key. The idea is that each user creates a public/private key pair for authentication purposes. The server knows the public key, and only the user knows the private key.
A private key file often has an associated passphrase for extra security. The key can only be used when the private key file can be read and the passphrase is supplied by the person running the program. We urge you to use a passphrase. The file ~/.ssh/authorized_keys in an account lists the public keys that are permitted for logging in. When the user logs in, the ssh program tells the server which key pair it would like to use for authentication. The client proves that it has access to the private key and the server checks that the corresponding public key is authorized for logins to the account.
Creating SSH KeysThe user creates his/her key pair by running ssh-keygen. This stores the private key in ~/.ssh/id_dsa (protocol 2 DSA), or ~/.ssh/id_rsa (protocol 2 RSA) and stores the public key in ~/.ssh/id_dsa.pub (protocol 2 DSA), or ~/.ssh/id_rsa.pub (protocol 2 RSA) in the user's home directory. By default, ssh-keygen creates RSA key files in ~/.ssh/.
The public key (eg: id_rsa.pub) should then be appended to the ~/.ssh/authorized_keys file of the account the person wants to access. The authorized_keys file has one key per line, though the lines can be very long. After this, the user can log in just by having the private key readable on their local computer.
Using SSH KeysWhen accessing the account the person provides the private key file (eg: id_rsa) and the passphrase that was used to create it and that is checked against the public key in the target account before access is granted. Supplying a private key to log in can be done like this:
ssh -i .ssh/id_rsa email@example.comThe most convenient way to use public key authentication may be with an authentication agent. A private key is registered with the agent along with its passphrase. After that the running agent program it will supply SSH connections with the registered key. See the ssh-agent for more information.
About PassphrasesExcept in rare circumstances an SSH key should be protected by a good passphrase. A passphrase is similar to a password, except it can be a phrase with a series of words, punctuation, numbers, whitespace, or any string of characters you want. Good passphrases are 10-30 characters long, are not simple sentences or otherwise easily guessable (English prose is generally easy to predict so makes a bad passphrases), and contain a mix of upper and lowercase letters, numbers, and non-alphanumeric characters. The passphrase is entered when the SSH key is generated. The passphrase can be changed later by using the -p option to ssh-keygen.
There is no way to recover a lost passphrase. If the passphrase is lost or forgotten, a new key pair must be generated and the public key copied to the corresponding target accounts.
The public key is in the target account but logins still do not workIf group write permission is enabled on the account directory this can stop users from sshing as the account even though the user's public-key has been appended to the authorized_keys file of the account. A description of this problem is given in the section about ~/.ssh/authorized_keys in the sshd manual page. The CSE SSH server is set with StrictModes=yes.
You need to make sure your home directory, .ssh directory and the authorized_keys are not group writable.
You forgot the passphrase to your private keyThere is no way to recover a lost passphrase. If the passphrase is lost or forgotten, a new key pair must be generated and the public key copied to the corresponding target accounts.
Your DSA (ssh-dss) key is not accepted by the ssh clientIt is stated in the OpenSSH documentation that OpenSSH 7.0 and greater disable the ssh-dss (DSA) public key algorithm because it is too weak. Users are highly recommended to re-generate a RSA key. If a user insists on using an existing DSA(ssh-dss) key, they should use the following workaround to manually enable DSA key use in the ssh user configuration(~/.ssh/config) file.
- create an user configuration file in ~/.ssh/config
- set permission of this file to 600
- add the following lines to enable DSA(ssh-dss) key for the nominated host (which in this example is login.cse.unsw.edu.au)
Host login.cse.unsw.edu.au pubkeyacceptedkeytypes +ssh-dss