Or, how do I log into an account without a password?
Public key authentication
Public key authentication works as follows: The scheme 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. ssh implements public key authentication protocol automatically, using one of the DSA, ECDSA or RSA algorithms. …
The file ~/.ssh/authorized_keys 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 to accept the account.
The user creates his/her key pair by running ssh-keygen (Wikipedia). This stores the private key in …
and stores the public key in …
- ~/.ssh/id_dsa (protocol 2 DSA),
- ~/.ssh/id_ecdsa (protocol 2 ECDSA), or
- ~/.ssh/id_rsa (protocol 2 RSA)
in the user's home directory. The user should then copy the public key to ~/.ssh/authorized_keys in his/her home directory on the remote machine. The authorized_keys file … has one key per line, though the lines can be very long. After this, the user can log in without giving the password.
- ~/.ssh/id_dsa.pub (protocol 2 DSA),
- ~/.ssh/id_ecdsa.pub (protocol 2 ECDSA), or
- ~/.ssh/id_rsa.pub (protocol 2 RSA)
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.
Except 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.
Creating SSH Keys
Run ssh-keygen, and see above.
We urge you to create your keys with a passphrase. The ssh-keygen program will prompt you to specify a passphrase when it creates the key files.
Granting access with a public key.
Please create your SSH public/private key pair (see above) before you ask anyone to grant you login access to an account.
The public key (eg: id_rsa.pub) should then be appended to the ~/.ssh/authorized_keys file in the account you want to log into.
Anyone who already has login access to the account can add your key. You should ask the person who oversees the account (eg: the most senior academic who uses it.) to add your public key.
You can also ask CSE System Support to add the key, though you will need to prove that it is appropriate for you to have access to the target account.
Using SSH Keys
When 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. Selecting a private key to use for authentication can be
done like this:
ssh -i keyfile.pub email@example.com
The 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(1) manual page for more information.
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