Encryption

Encryption mainly keeps data safe during transmission. It combines asymmetric and symmetric encryption. Asymmetric encryption protects the transmission of the shared passphrase; using that shared passphrase for subsequent encryption is more efficient. The initial asymmetric stage relies on the server’s public and private key pair.

To prevent man-in-the-middle attacks and theft of the symmetric key, SSH also sends the client a public-key fingerprint identifying the host when connecting to a new host. The client must first verify the host’s identity. Log in to the host, run cd /etc/ssh, and then use kengen -lf filenName to check whether the two match. Once accepted, the host is added to the known_hosts file and does not need to be verified again on the next login.

Authentication

Authentication happens on top of encryption: the entire communication is already encrypted. Its main purpose is to verify whether the user is authorized to log in.

1. Direct password authentication.

Simply put, the service compares passwords. This is straightforward, but it carries the risk of brute-force attacks and is also vulnerable to man-in-the-middle attacks.

1. Adding a public key.

Unlike direct password login, this method primarily lets the server verify the user’s identity through a “key challenge” (in theory, only someone who possesses the private key can pass it).

The “key challenge” process

Locally, a passphrase (the password used to decrypt the private key) can also protect the private key, adding another layer of security.

This approach is more involved, of course. You must first log in to the remote server by another method and transfer the client’s public key to it (then disable password login for security).

[Only the client’s private key and public key are used here]