To enable sshd to receive connection requests from ssh, the following requirements must be met for sshd:
A host key (RSA, DSA, ECDSA or Ed25519) exists on the computer on which sshd is running (server computer). The host key is key pair consisting of a private key and a public key and identifies the server. This requirement is already satisfied by installation in POSIX.
The following activities are performed for every ssh connection request:
sshd sends the public part of its host key and a list of the encryption algorithms it supports to ssh. The encryption methods that can be used at present are AES, ChaCha20 or 3DES
ssh checks whether it recognizes sshd by looking to see if a public key is stored for the respective system in the user's file $HOME/.ssh/known_hosts or in the file provided centrally by the system administrator /etc/ssh/ssh_known_hosts, and if this is the case, whether it matches the host key type sent from sshd (RSA/DSA/ECDSA/Ed25519):
If a public key is stored for the respective system and it is identical to the public host key sent from sshd, proceed to step 3).
If a key is stored, but it is not identical to the host key sent from sshd, there are two possible causes:
The sshd host key has just been generated (harmless variation).
Somebody is currently attempting an active "man-in-the-middle" attack (MITM attack) on the SSH connection.
In this situation, ssh displays a relevant warning and you should only dismiss this if you are sufficiently certain that a) is true.
If you dismiss the warning, then ssh proceeds as though no key is stored.
If the host key is not contained in these files, ssh calculates a fingerprint from the public host key sent from sshd. If ssh is configured accordingly (VerifyHostKeyDNS Yes), ssh fetches the host key fingerprint from DNS (if it is stored there) and compares it with the fingerprint calculated. Otherwise, ssh displays the calculated fingerprint and asks the user if it is OK.
If the two fingerprints do not match, the user answers the question with "no" and ssh terminates the connection.
If the answer is "yes", ssh enters the host key in the file $HOME/.ssh/known_hosts so that it is subsequently known and the change of host key, which may signal a potential MITM attack, is noted. This only applies, however, if the StrictHost-KeyChecking option in the configuration file ssh_config is not set to yes. Otherwise, you must add the correct contents to the file
$HOME/.ssh/known_hosts manually.
For a detailed description of the StrictHostKeyChecking option, see the OpenSSH man pages.
ssh and sshd exchange various data. These files are used, on the one hand, to perform a Diffie-Hellman key exchange to obtain one shared session key. On the other hand, sshd also sends data, which it has signed with its private host key. ssh can use this signature to determine whether sshd is really in possession of the private host key belonging to the public host key transmitted.
Both sides use the session key for encrypting all communication in the current session. The rest of the session is encrypted using a symmetrical encryption method. Currently AES, ChaCha20 oder 3DES is used essentially for this purpose. ssh selects the encryption algorithm from the list which it received from sshd together with the host key (see step 2).
The session key is also used for ensuring data integrity using a MAC method (message authentication code), which ssh also selects from the list provided by sshd in step 1. Such methods include HMAC-SHA2, HMAC-SHA1, or UMAC in their various forms.
The client and sshd now conduct an authentication dialog in which the client proves its identity and authorization to sshd.
Details on client authentication can be found in the section “Authentication between OpenSSH client ssh and server sshd”.
sshd authenticates itself implicitly to the client as it can only ascertain the session key generated and encrypted by the client if it knows its private RSA keys.