spoofing. [Note to the administra‐
tor: /etc/hosts.equiv, ~/.rhosts, and the rlogin/rsh protocol in gen‐
eral, are inherently insecure and should be disabled if security is de‐
sired.]
Public key authentication works as follows: The scheme is based on pub‐
lic‐key cryptography, using cryptosystems where encryption and decryp‐
tion are done using separate keys, and it is unfeasible to derive the
decryption key from the encryption key. The idea is that each user cre‐
ates a public/private key pair for authentication purposes. The server
knows the public key, and only the user knows the private key. ssh im‐
plements public key authentication protocol automatically, using one of
the DSA, ECDSA, Ed25519 or RSA algorithms. The HISTORY section of
ssl(8) (on non‐OpenBSD systems, see
http://www.openbsd.org/cgi-bin/man.cgi?query=ssl&sektion=8#HISTORY) con‐
tains a brief discussion of the DSA and 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 server may inform the client of errors that prevented public key au‐
thentication from succeeding after authentication completes using a dif‐
ferent method. These may be viewed by increasing the LogLevel to DEBUG
or higher (e.g. by using the -v flag).
The user creates their key pair by running ssh‐keygen(1). This stores
the private key in ~/.ssh/id_dsa (DSA), ~/.ssh/id_ecdsa (ECDSA),
~/.ssh/id_ecdsa_sk (authenticator‐hosted ECDSA), ~/.ssh/id_ed25519
(Ed25519), ~/.ssh/id_ed25519_sk (authenticator‐hosted Ed25519), or
~/.ssh/id_rsa (RSA) and stores the public key in ~/.ssh/id_dsa.pub
(DSA), ~/.ssh/id_ecdsa.pub (ECDSA), ~/.ssh/id_ecdsa_sk.pub (authentica‐
tor‐hosted ECDSA), ~/.ssh/id_ed25519.pub (Ed25519),
~/.ssh/id_ed25519_sk.pub (authenticator‐hosted Ed25519), or
~/.ssh/id_rsa.pub (RSA) in the user’s home directory. The user should
then copy the public key to ~/.ssh/authorized_keys in their home direc‐
tory on the remote machine. The authorized_keys file corresponds to the
conventional ~/.rhosts file, and has one key per line, though the lines
can be very long. After this, the user can log in without giving the
password.
A variation on public key authentication is available in the form of
certificate authentication: instead of a set of public/private keys,
signed certificates are used. This has the advantage that a single
trusted certification authority can be used in place of many public/pri‐
vate keys. See the CERTIFICATES section of ssh‐keygen(1) for more in‐
formation.
The most convenient way to use public key or certificate authentication
may be with an authentication agent. See ssh‐agent(1) and (optionally)
the AddKeysToAgent directive in ssh_config(5) for more information.
Keyboard‐interactive authentication works as follows: The server sends
an arbitrary "challenge" text and prompts for a response, possibly mul‐
tiple times. Examples of keyboard‐interactive authentication include
BSD Authentication (see login.conf(5)) and PAM (some non‐OpenBSD sys‐
tems).
Finally, if other authentication methods fail, ssh prompts the user for
a password. The password is sent to the remote host for checking; how‐
ever, since all communications