What is SSH (Secure Shell)? How SSH (Secure Shell) works.

Most people who use SSH never think about how it works. They type ssh user@host, enter a password or let their key handle authentication, and that’s it. But if you understand what happens under the hood, you’ll not only debug problems faster—you’ll also appreciate why SSH is one of the most robust tools in networking.

SSH was created to replace insecure protocols like Telnet and FTP. Before SSH, sending your password over a network was like shouting it across a crowded room. SSH encrypts everything, from your password to the commands you run.

The current standard is SSH2. If you’re still using SSH1, stop. SSH2 fixes critical flaws and adds stronger encryption.

The Connection

When you run ssh user@host, the first thing that happens is a TCP connection on port 22. This is the same as any other network connection—like loading a webpage, but without encryption yet.

Once connected, the client and server agree on which version of SSH to use. This is version negotiation. If the server only supports SSH2 and you’re stuck on SSH1, the connection fails here.

Next, they decide how to talk securely. This is algorithm negotiation. The client and server compare lists of supported encryption methods, hash algorithms, and key exchange protocols, then pick the best overlap. If you’ve ever seen an error like “no matching key exchange method,” this is where it happens.

Key Exchange

Now comes the interesting part. The client and server need to agree on a shared secret without ever sending it directly. They do this using the Diffie-Hellman key exchange (often the elliptic curve variant today).

Here’s how it works:

1. Both sides generate temporary key pairs.
2. They exchange public keys.
3. Each side combines the other’s public key with its own private key to compute the same shared secret.

This shared secret becomes the session key. Even if someone intercepts the public keys, they can’t derive the session key without the private keys. And since the keys are temporary, past sessions stay secure even if future keys are compromised — a property called perfect forward secrecy.

Authentication

With encryption set up, the server needs to verify you’re allowed to connect. The best method is public key authentication.

The server checks if your public key (usually in ~/.ssh/authorized_keys) matches the private key you’re using. To prove you own the private key, the server sends a random number encrypted with your public key. If you can decrypt it and send it back, you’re in.

Password authentication is still an option, but it’s less secure. If someone intercepts your session, they might brute-force the password. With public keys, they’d need your private key — much harder to steal.

The Session

Once authenticated, everything you send or receive is encrypted with the session key. Type a command, and it’s encrypted before leaving your machine. The server decrypts it, runs the command, encrypts the output, and sends it back.

This isn’t just for running commands. SSH can also forward other traffic — like accessing a database or web server as if it’s running locally. This is called SSH tunneling, and it’s useful for bypassing firewalls or securing unencrypted protocols.

Why It Matters

SSH is one of those tools that works so well people forget it exists. But its design is worth studying. The combination of forward secrecy, strong encryption, and flexible authentication makes it both secure and practical.

Most security flaws happen because people misuse tools, not because the tools themselves are broken. If you understand how SSH works, you’re less likely to misconfigure it — and more likely to spot when someone else has.

Frequently Asked Questions About SSH

Q1: What is SSH and why is it important?

SSH (Secure Shell) is a network protocol that enables secure remote access to computer systems over unsecured networks. It’s a cornerstone of modern network security because it encrypts the communication between a client and a server, protecting against eavesdropping and man-in-the-middle attacks. This makes it the go-to protocol for various tasks, including remote server administration and secure file transfers.

Q2: What is the difference between SSH1 and SSH2?

The source specifically mentions SSH2 as the current standard, standardized by the Internet Engineering Task Force. SSH2 provides significant security improvements over its predecessor, SSH1. These enhancements include the use of stronger encryption algorithms and more robust authentication methods, making SSH2 much more secure and the recommended version for all SSH connections.

Q3: How does an SSH connection begin?

The initial connection process involves several steps. First, the SSH client initiates a TCP connection to the server, typically on port 22. Once this connection is established, the client and server engage in version negotiation to ensure they can communicate using the same version of the SSH protocol. Following this, they perform algorithm negotiation, where they agree on the cryptographic algorithms to be used for key exchange, encryption, and integrity checking throughout the session.

Q4: What is key exchange and why is it crucial for security?

Key exchange is a critical step in the SSH handshake where the client and server establish a shared secret key. The source highlights the use of the Elliptic Curve Diffie-Hellman method for this process. Both sides generate temporary (ephemeral) key pairs and exchange their public keys to dynamically create a shared secret. This shared secret is then used for symmetric encryption of all subsequent data. The use of ephemeral keys provides perfect forward secrecy, ensuring that even if current or future keys are compromised, past communication remains secure.

Q5: How does SSH authenticate the client?

SSH primarily uses public key authentication to verify the client’s identity. The server checks its authorized key files (typically ~/.ssh/authorized_keys on Unix-like systems) for a public key that matches the one presented by the client. If a match is found, the server sends a challenge to the client in the form of a random number encrypted with the client’s public key. Only the client possessing the corresponding private key can decrypt this number and send it back to the server, thus proving their identity. While SSH also supports password-based authentication, public key authentication is considered more secure.

Q6: What happens after successful authentication in an SSH session?

Once the client is successfully authenticated, the SSH session is fully established. All subsequent communication between the client and the server is encrypted using the shared session key derived during the key exchange. This includes commands sent from the client to the server, as well as the results and responses sent back from the server to the client. This end-to-end encryption ensures the confidentiality and integrity of the data exchanged during the entire SSH session.

Q7: Is SSH only for executing remote commands?

No, while remote command execution is a primary use case for SSH, it also supports other valuable features. The source specifically mentions SSH local forwarding, which allows users to create secure tunnels for other network services through the encrypted SSH connection. This can be particularly useful for accessing services that might be blocked by firewalls or for adding a layer of encryption to protocols that are otherwise unencrypted.

Q8: What makes SSH a secure protocol?

SSH achieves its security through a combination of mechanisms. These include strong encryption of all transmitted data, robust authentication methods like public key cryptography, and the use of secure key exchange algorithms with perfect forward secrecy. The initial negotiation phase ensures that both the client and server agree on secure cryptographic parameters. By encrypting the entire session, SSH effectively protects against eavesdropping, data tampering, and unauthorized access to remote systems.