In the article “Understanding SSH Tools, Essential for Developers,” the conceptual introduction to SSH knowledge is aimed at making SSH tools more practical for most users. For example, in my case, a successful SSH password login provides the motivation to explore other SSH functionalities.
What is SSH Login?
There are typically two methods for SSH login: password authentication and key pair authentication. Password login is straightforward—execute ssh root@localhost, enter the correct password, and achieve successful login.
What is SSH Protocol?
But do you know the underlying details? This is the purpose of my article. Similar to TLS protocol, SSH protocol combines various cryptographic algorithms to address network security issues. Understanding the principles of SSH protocol is beneficial for grasping cryptography, which includes numerous algorithms like AES symmetric key algorithm, public key algorithms (DH key exchange, RSA asymmetric encryption), MAC algorithms, and hash algorithms. Familiarity with these algorithms simplifies the understanding of SSH protocol; otherwise, it can be challenging.
Another advantage of understanding SSH protocol is maintaining composure when troubleshooting and using SSH more securely.
The article begins with the relatively simple SSH password login. Before diving into it, let’s understand three sub-protocols of the SSH protocol:
- Transport Layer: Operates above TCP/IP, responsible for key exchange and server authentication, ensuring encrypted and integrity-checked data channels.
- User Authentication Layer: Servers authenticate clients using either password or key pair authentication methods. It’s important to note that client authentication is client-driven, allowing the client to choose the specific authentication method.
- Connection Layer: Establishes an encrypted channel for use by other application layer protocols.
Of these protocols, the last one is relatively complex, and this article primarily focuses on the first two.
How to Achieve SSH Password Login Easily
SSH password login involves two phases: first, negotiating a session key to establish a secure channel between the client and server; second, using this channel to verify the client’s login credentials.
SSH Password Login Phase 1
SSH servers typically bind to port 22, listening for client requests. Upon startup, they generate a key pair (public and private keys), usually RSA algorithm key pairs. During the first phase, the server sends the public key to the SSH client to confirm the server’s identity. Besides this role, I have not encountered other uses for this key pair.
Why do I say “currently”? Because I have not reviewed the SSH RFC documents; my understanding of SSH protocol is based on conceptual guessing through packet capture using Wireshark.
Check out this diagram to see the packets generated during SSH login. You can use Wireshark to capture packets and filter out SSH packets (excluding TCP packets).
Here is the translation of the provided content into English:
“The red line represents the first phase of SSH login, which typically begins with entering ssh root@localhost.
Additionally, the blue lines depict the second phase of SSH login, where these packets are generated after entering the password.
Next, let’s first discuss what happens in the first phase:
- The client initiates a connection request (sequence number 4), informing the server about the SSH version it supports.
- The server responds with its SSH version, and typically, both sides negotiate to use SSH v2.
- The client initializes the connection (sequence number 9), performs key exchange, and informs the server about the various algorithms it supports, as shown in the diagram.”
- Then the server informs the client about the various algorithms it supports (sequence number 10), and finally, they negotiate to agree on a set of algorithms. The server also sends the public key of its public-private key pair.
- During the first SSH login, the SSH client prompts the user to verify the fingerprint of the server’s public key (i.e., the MD5 value of the public key). Of course, this verification step is not visible in network packets.
If you are logging into SSH for the first time, you will encounter the following:
If you confirm that the fingerprint matches the SSH server you intend to connect to, the public key will be saved to the ~/.ssh/known_hosts file. The next time you log in, the SSH client will compare the fingerprint it receives from the server with the one stored in known_hosts. If they match, the client will not prompt you for confirmation again.
Fingerprints are crucial, and I will elaborate on this later.
- Next, the client proceeds to send its public key for the DH algorithm (sequence number 13). Note that this key pair is distinct from the server’s public-private key pair.
Both the client and the server retain their own private keys for the DH key pair and exchange their respective public keys. This enables them to negotiate the final session key (used for symmetric encryption).
I won’t delve further into the DH algorithm here, but if you’re interested, you can check out my book “Understanding HTTPS: From Principles to Practice.” This algorithm is highly secure; even if hackers intercept network traffic or gain access to machines, they cannot crack it because the private keys remain in memory and are not transmitted over the network.
Details are as shown in the diagram below:
- The server sends its public key for the DH algorithm (sequence number 15), and both parties negotiate a session key known only to them.
- The client sends a New Keys packet (sequence number 16), indicating that both parties have established an encrypted channel.
The above describes the first phase of SSH login. In the second phase, data generated is encrypted using the session key.
SSH Password Login Phase 2
The second phase is relatively straightforward. The client decides on the authentication method. If it’s password authentication, the client encrypts the password and sends it to the server. If the server verifies it successfully, the login is successful. Details are as shown in the diagram below:、
Is This SSH Password Login Method Secure?
Relatively, yes, because passwords are not transmitted in plaintext.
However, this method is vulnerable to man-in-the-middle attacks. Remember that fingerprint? In reality, very few people verify whether the fingerprint belongs to the “genuine SSH server.” It’s a long string of numbers, and manually calculating and comparing it against the server’s public key can be quite challenging.
If you don’t verify it, there could be risks. Imagine if, during connection, a hacker intercepts your data packets and sends their own public key instead. If you haven’t verified the fingerprint, all subsequent SSH data packets would be communicating with the hacker, who could then potentially obtain the server’s password.
The danger lies in believing you’re communicating with the “real SSH server” when, in fact, you’re communicating with a hacker. Is there a good solution? If using password authentication, there isn’t one. Therefore, I will introduce another login verification method later on.