[00:00] Welcome to this quick video on how SSH works. If you ever wonder how this essential protocol secures your remote connections, stick around as we break down how SSH creates a secure tunnel between client and server.
[00:13] SSH was developed to provide secure remote access over unsecured networks, and it's become a cornerstone of modern network security. It's the go-to protocol for tasks ranging from remote server administration
[00:25] to secure file transfers. Today we are focusing on SSH2, the version standardized by the Internet Engineering Task Force. SSH2 provides significant security improvements over SSH1,
[00:39] including stronger encryption algorithms and enhanced authentication. Let's start with the initial connection. When an SSH client attempts to connect to a server, it begins by establishing a TCP connection, typically over port 22.
[00:53] Once the TCP connection is in place the client and server start version negotiation This step ensures both parties are speaking the same language agreeing on which version of the SSH protocol they will use for this session
[01:08] Next come algorithm negotiation. Here the client and server decide which cryptographic algorithms they will use for tasks like key exchange, encryption, and integrity checking. This negotiation allows SSH to adapt to different security requirements and computational capabilities.
[01:24] With the preliminary done, we reach a critical step in the SSH handshake, key exchange. Typically, the client and server use the elliptic curve Diffie-Hellman method to generate a shared session key.
[01:37] In this process, both sides generate ephemeral key pairs and exchange their public key to dynamically create a shared secret for encryption. The use of ephemeral keys provides perfect forward secrecy,
[01:50] meaning that even if the keys are compromised in the future, past session data remains secure. This shared secret key is then used for symmetric encryption which encrypts all the data transmitted during the SSH session Now the client initiates a login request to the server The server then performs a critical
[02:08] security check by looking at a matching public key in its authorized key files, typically located in tilde.ssh authorized keys on Unix-like systems. This method, known as public key authentication,
[02:21] is the most common way to verify that clients is allowed to connect to the server. SSH also supports password-based authentication, although it is less secure compared to public key authentication.
[02:33] If the server finds a matching key, it encrypts a random number using the client's public key and sends it back to the client. This challenge serves two purposes. It proves that the server has the correct public key and ensures that the client processes the corresponding private key.
[02:49] The client then decrypts this random number using its private key. By successfully decrypting the data and sending it back to the server the client proves its identity The server verifies the decryption confirming that the client is who it claims to be Once the authentication is complete the SSH session is fully established
[03:09] From this point on, all commands sent from the client to the server are encrypted with the session key. The server executes these commands, encrypts the result using the same session key, and sends them back to the client.
[03:21] The client then decrypts this result using the session key. key. This encrypted back and forth continues for the duration of the SSH session. SSH isn't for remote command execution. It also supports features like SSH local forwarding, which allows you to
[03:37] tunnel other network services through the SSH connection. This can be especially useful for accessing services that might otherwise be blocked by firewalls, or for adding a layer of security to unencrypted protocols. If you like our videos, you might like our system design newsletter as well.
[03:54] It covers topics and trends in large-scale system design. Trusted by a million readers.