SSH

When you spin up a cloud server or need to manage a remote machine, you cannot physically sit in front of it. You have to send commands over the network, but older methods like Telnet and rlogin transmit passwords and commands in plaintext. The moment traffic crosses a shared network or the internet, anyone can intercept and read it, immediately exposing server management credentials. With one or two servers you might get by with physical access, but managing dozens of cloud instances by attaching to each console is unrealistic. SSH is a protocol that encrypts all remote access traffic, making it safe to manage servers even over untrusted networks.

In the early internet, remote access relied on plaintext protocols like Telnet, rlogin, and FTP. When networks were confined to universities and research labs, the risk of eavesdropping was not significant. But as the internet became public infrastructure, anyone on an intermediary network could sniff packets. Server administrator passwords were repeatedly leaked through packet sniffing, and stealing server access credentials meant gaining full system control. As this risk materialized in operational costs and security incidents, encrypting remote access itself became urgent. SSH emerged as the answer, rapidly replacing Telnet and rlogin to become the de facto standard for server management. The fact that connecting to cloud instances via SSH is taken for granted today is the result of that transition.

An SSH connection starts by establishing a regular TCP connection to port 22. Once connected, the client and server verify each other's protocol versions, then share a symmetric session key using a key exchange algorithm like Diffie-Hellman. During this process, the server presents its host key and the client compares it against what it knew previously to detect impersonation. After key exchange, all subsequent data travels through the encrypted channel. User authentication follows, either by sending a password or by using a public/private key pair. With public key authentication, the client signs a value with its private key and the server verifies it with the registered public key, so no password ever crosses the network. Once authenticated, multiple channels can be opened over the single encrypted connection, allowing you to maintain a shell session while simultaneously transferring files or setting up port forwarding.

SSH and TLS both create encrypted communication channels, but their purpose and scope differ. TLS is a general-purpose security layer that encrypts application protocols like HTTP, email, and database connections between browsers and servers. SSH is specialized for remote server management, handling shell access, file transfer, port forwarding, and user authentication all within one protocol. For encrypting web traffic, TLS (HTTPS) is the right fit; for remotely entering a server to execute commands or move files, SSH is the right fit. They are more accurately seen as encryption layers for different purposes rather than as substitutes for each other.

SSH is the default tool for virtually every operational task that involves directly handling servers: cloud instance access, on-premises server operations, CI/CD deployment automation, and remote file transfer. Setting up public key authentication allows secure connections without passwords, fitting well with automation pipelines. Port forwarding enables creating temporary tunnels to internal services that are not directly exposed. However, an open SSH connection means a path to server management authority exists. Leaving port 22 open to the entire internet makes the server an easy target for brute-force login attempts, and failing to manage public keys properly can leave former employees' keys on servers. So SSH must be designed alongside controls for whose keys are registered on which servers and which source IPs are allowed to connect.