In SSH, it is also necessary that the server authenticates itself to the client.
Otherwise, a man-in-the-middle (or any other party capable of manipulating the connection, e.g., via DNS spoofing) could impersonate the server and trick the client into revealing its password or, in the case of public-key authentication, a valid response to a cryptographic challenge (which the attacker may then use to log in at the real server).
This authentication step is done via the server's host keys.
Section 8 of RFC 4253 states:
The key exchange is combined with a signature with the host key to provide host authentication.
Typically, servers support more than one signature algorithm for interoperability reasons, hence they need to tell the client which key types they have available: The server_host_key_algorithms
field contains this list.
That mechanism is the reason you see the following (probably familiar) warning when first connecting to some server:
The authenticity of host 'example.org (192.0.2.121)' can't be established.
ECDSA key fingerprint is SHA256:Lj0PQQnA9K2NupAxdjJSnxQhVWoVvjTLcUQQWDFS+9A.
Are you sure you want to continue connecting (yes/no)?
Here, the client essentially asks you to confirm that you have verified the server's host key. After the first connection, the client stores the server's host key in its known_hosts
file and will only warn the user again if the host key changes (for instance, if the server has been reinstalled or there really is an attack taking place).