Following our deep dive into TLS, we encounter SSH. While TLS is designed to protect a stream of data between a client and a server, SSH is a full-featured application suite designed for secure remote login and command execution. It doesn't just encrypt the wire; it manages the entire lifecycle of a remote session.
The Transport Layer is the first to engage. Its primary goal is to establish a secure, encrypted channel. It handles key exchange (Kex), server authentication, and initializes the symmetric encryption and MAC algorithms that will protect all subsequent communication. If the Transport Layer fails, the connection is severed before the user even enters a password.
💡 Unlike HTTPS, which usually terminates at a load balancer, SSH is almost always a direct end-to-end connection between the administrator's machine and the target server.
In the output above, you see the version string exchange and the 'kex' (key exchange) negotiation. This is where the client and server agree on the shared secret, utilizing the Diffie-Hellman principles we studied in Module 1.
Once the Transport Layer has encrypted the pipe, the Authentication Layer takes over. Its sole purpose is to prove the identity of the client to the server. This layer is modular; it can support passwords, public keys, keyboard-interactive prompts, or GSSAPI (Kerberos). Crucially, the authentication happens *inside* the encrypted tunnel, meaning passwords are never sent in cleartext.
Security Note: Because authentication happens after encryption, a 'brute force' attack on SSH is not a matter of sniffing passwords, but of guessing them and sending them through the tunnel.
| Layer | Main Goal | Key Protocols Used | Failure Result |
|---|---|---|---|
| Transport | Confidentiality | Diffie-Hellman, AES, HMAC | Connection Refused |
| Authentication | Identity | RSA/Ed25519, Password | Permission Denied |
| Connection | Functionality | TCP Channels, Shells, Port Forwarding | Session Closed |
The Connection Layer multiplexes the secure tunnel into several logical channels. This allows a single SSH connection to do multiple things at once: you can have an interactive shell open in one window, while simultaneously transferring a file via SFTP and forwarding a remote database port to your local machine—all over one encrypted TCP connection.
A common mistake is thinking that an SSH tunnel secures the application. If you tunnel an insecure app (like an old HTTP site), the data is encrypted *between* the SSH endpoints, but is still plaintext *inside* the server after the SSH daemon decrypts it.
Verify exercises to earn ★ 130 XP and unlock next lab level.