What Is SSH?

Before SSH existed, logging into a remote server was like shouting your password across a crowded room and hoping only the right person heard it.

That's not hyperbole. Telnet, the dominant remote access protocol of the early Internet, transmitted everything in plain text—usernames, passwords, every command you typed, every response you received. Anyone on the network path between you and the server could watch the entire conversation. They could capture your credentials and walk right in.

SSH (Secure Shell) solved this by wrapping everything in encryption so strong that eavesdroppers see only random noise. It's now so fundamental to server administration that imagining the alternative feels like imagining surgery without anesthesia.

The Handshake

When you type ssh username@server, a carefully choreographed dance begins.

First, the server sends its public key—its identity card. Your client checks: have I seen this server before? If not, it shows you the server's fingerprint and asks you to verify. This matters. An attacker pretending to be your server would have a different fingerprint. That warning you click through on first connection? It's the only thing standing between you and a man-in-the-middle attack.

Next comes the beautiful part: key exchange. Two machines that have never met, communicating over a network they can't trust, need to establish a shared secret. If they just sent the secret directly, anyone watching could grab it. Instead, they use asymmetric cryptography—each side contributes randomness, and through mathematical operations involving public and private keys, both arrive at the same shared secret without ever transmitting it. Anyone watching sees the exchange but can't derive the secret. This is the Diffie-Hellman key exchange, and it's one of the most elegant solutions in all of cryptography.

With the shared secret established, they switch to symmetric encryption—faster for the actual session. Now everything travels through an encrypted tunnel. Your password (if you're using one), your commands, the server's responses—all encrypted before transmission, decrypted on arrival.

Authentication: Proving You're You

Password authentication works exactly as you'd expect. You send your password, encrypted by the session key you just established. The server checks it against its records. Simple, familiar, and increasingly discouraged.

Key-based authentication is more interesting. You generate a key pair: a private key you guard jealously, a public key you can share with anyone. You place your public key on servers you want to access.

When you connect, the server doesn't ask for a password. Instead, it generates a random challenge and encrypts it with your public key. Only the matching private key can decrypt it. Your client decrypts the challenge with your private key and sends back a signature proving it succeeded. The server verifies the signature.

Your private key never leaves your machine. Never travels the network. Even if someone captures every packet of your SSH session, they can't extract your private key from it. This is why organizations disable password authentication entirely—key-based auth is simply more secure.

Using SSH

The basics are simple:

ssh username@hostname

That connects to hostname as username on port 22 (SSH's default). Add -p 2222 if the server uses a different port. Add -i /path/to/key to specify which private key to use.

Once connected, you're at a command prompt on the remote machine. Type commands. See output. Type exit when done.

But SSH does far more than provide a remote shell.

Secure file transfer: scp localfile.txt user@server:/path/ copies files through the encrypted tunnel. SFTP provides an interactive file browser, also encrypted.

Port forwarding: Tunnel other protocols through SSH's encryption. ssh -L 8080:localhost:80 user@server makes the server's port 80 available as your local port 8080—useful for accessing web interfaces that aren't publicly exposed, or for protecting protocols that lack their own encryption.

Remote command execution: ssh user@server 'df -h' runs a command and returns the output without an interactive session. This is how automated scripts talk to remote machines.

X11 forwarding: Run graphical applications on the server, display them locally. ssh -X user@server enables this—though modern workflows usually find other ways to handle GUIs.

Configuration

Typing the same options repeatedly is tedious. SSH's config file (~/.ssh/config on Unix-like systems) solves this:

Host myserver
    HostName 192.168.1.50
    User admin
    Port 2222
    IdentityFile ~/.ssh/myserver_key

Now ssh myserver expands to all those options automatically.

Other useful configurations:

• Connection multiplexing: Reuse existing connections for new sessions to the same server, dramatically speeding up subsequent connections
• Keep-alive messages: Prevent idle connections from timing out
• Agent forwarding (-A): Use your local keys when SSHing from the remote server to other servers—convenient but carries security risks

Security Practices

SSH is secure by design, but you can still use it insecurely.

Verify host keys. That fingerprint warning on first connection isn't bureaucratic noise. If you click through without verifying, you might be handing your credentials to an attacker. If the fingerprint changes on a server you've connected to before, something is wrong—investigate before proceeding.

Protect your private keys. File permissions should be 600 (readable only by you). Add a passphrase for encryption at rest. Never commit them to version control. Never share them.

Disable password authentication once key-based auth is working. One fewer attack surface.

Disable root login. Use a regular account and escalate with sudo when needed.

Use fail2ban or similar tools to block IPs that fail authentication repeatedly—stops brute-force attacks cold.

Keep SSH updated. Vulnerabilities are occasionally discovered. Updates fix them.

SSH Everywhere

SSH has become the universal language of remote server access. System administrators use it constantly. Deployment pipelines run over it. Configuration management tools like Ansible use it as their transport. Git hosting platforms like GitHub and GitLab support SSH for pushing and pulling code.

Alternatives exist—RDP for Windows graphical access, Mosh for unreliable connections, various proprietary solutions—but for secure command-line access to Unix-like systems, SSH won decades ago and shows no signs of yielding.

The protocol that replaced plain-text passwords with mathematical elegance isn't going anywhere.