Understanding SSH: How Secure Remote Login Works and How to Set It Up

1. Introduction to SSH

SSH is a protocol standard designed for secure remote login and other secure network services .

SSH is only a protocol standard ; there are many implementations, both open‑source such as OpenSSH and commercial solutions. The most widely used implementation is the open‑source OpenSSH.

2. How SSH Works

Before discussing SSH’s principles and usage, we need to ask: Why do we need SSH?

Compared with telnet, FTP and similar protocols, SSH’s main difference is security . This raises the question: How is data secured? The obvious answer is encryption , which can be either:

Symmetric encryption (key encryption)

Asymmetric encryption (public‑key encryption)

Symmetric encryption uses the same key for encryption and decryption, as shown in the following diagrams:

Server:

While symmetric encryption is strong, it raises a critical problem: How to store the keys securely? With many clients, protecting the keys from leakage is difficult. If a client’s key is compromised, the entire system’s security collapses. Asymmetric encryption solves this by using two keys: a public key and a private key .

The public key encrypts data that can only be decrypted with the matching private key; deriving the private key from the public key is practically impossible.

The login flow using asymmetric encryption is:

1. The remote server sends its public key to the client.

2. The client encrypts the password with this public key.

3. The client sends the encrypted password to the server.

4. The server decrypts the password with its private key and validates it.

5. The server responds to the client.

The private key resides only on the server, ensuring that even if the encrypted data is intercepted, it cannot be decrypted without the private key.

Is this always safe?

A potential issue is how the client can be sure that the received public key truly belongs to the intended server. An attacker could perform a man‑in‑the‑middle attack by sending their own public key, allowing them to decrypt the intercepted data.

How Does SSH Solve This Problem?

1. Password‑Based Authentication

SSH must verify the server’s public key. Unlike HTTPS, which uses a CA, SSH’s keys are self‑generated. The client must manually confirm the server’s key, typically on the first connection:

The authenticity of host 'ssh-server.example.com (12.18.429.21)' can't be established.<br/>RSA key fingerprint is 98:2e:d7:e0:de:9f:ac:67:28:c2:42:2d:37:16:58:4d.<br/>Are you sure you want to continue connecting (yes/no)?<br/>

The fingerprint is a short hash of the long RSA public key, making comparison feasible.

If the user answers yes , the host is added to the known_hosts file and the user is prompted for a password:

Warning: Permanently added 'ssh-server.example.com,12.18.429.21' (RSA) to the list of known hosts.<br/>Password: (enter password)<br/>

2. Public‑Key Authentication

To avoid entering a password each time, SSH supports key‑based login:

1. The client’s public key is placed on the server in authorized_keys .

2. Upon connection, the server encrypts a random number R with the client’s public key and sends it.

3. The client decrypts R with its private key, then creates a digest of R and the session key (Digest1) and sends it to the server.

4. The server generates its own digest (Digest2) using the same algorithm.

5. The server compares Digest1 and Digest2; if they match, authentication succeeds.

Adding the public key to authorized_keys is a manual step; the following screenshot shows GitHub’s SSH key settings.

3. SSH Practice

Generating Keys

Based on the principles above, the following three commands generate and install a key pair:

<span>$ </span>ssh-keygen -t rsa -P '' -f ~/.ssh/id_rsa<br><span>$ </span>cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys<br><span>$ </span>chmod 0600 ~/.ssh/authorized_keys

ssh-keygen

creates the key pair. Options:

-t: key type (rsa, dsa, ecdsa, …)

-P: passphrase for protecting the private key

-f: file path for the keys (public key gets a .pub suffix)

The ~/.ssh directory contains four important files:

id_rsa – private key

id_rsa.pub – public key

authorized_keys – public keys authorized to log in

known_hosts – host keys of servers the client has trusted

The relationship among these files is illustrated below:

A single host can act as both client and server, thus possessing both authorized_keys and known_hosts .

Login Commands

# Log in to remote host as user "user"
$ ssh user@host
# If local and remote usernames are the same, omit the username
$ ssh host
# Change the default port (22) with -p
$ ssh -p 2017 user@host

4. Summary

This article visually explains SSH fundamentals (focused on remote login, not port forwarding), analyzes asymmetric encryption characteristics, and demonstrates practical steps for secure key management and password‑less authentication.

What does known_hosts store?

It stores the host keys of remote servers that have been verified.

When is a host key added to known_hosts ?

During the first SSH connection, after the user confirms the host’s authenticity, the key is added.

Why is known_hosts needed?

It enables the client to verify the server’s identity, preventing man‑in‑the‑middle attacks through mutual authentication.

This approach balances security and usability; the initial connection to an unknown server remains a potential attack vector.