What Is SSH and How Does It Work?

SSH (Secure Shell) is a network protocol that lets you securely operate a remote computer over an untrusted network as if you were sitting in front of it. It encrypts every byte exchanged so that login credentials, commands, and output cannot be read or tampered with by anyone watching the wire.

What SSH Is

When you run a command like ssh user@server, your machine (the client) opens an encrypted channel to a program on the remote machine (the server, traditionally called sshd) listening on TCP port 22. Once the channel is up, anything you type is encrypted before it leaves your computer and decrypted only on the server, and the same protection applies to everything coming back.

SSH replaced older remote-access tools such as Telnet, rlogin, and rsh, which sent everything (including passwords) in plain text. The modern protocol is SSH-2, standardized by the IETF in a series of RFCs (notably RFC 4251 through RFC 4254). The most widely deployed implementation is OpenSSH, which ships by default on Linux, macOS, the BSDs, and recent versions of Windows.

How SSH Works: The Three Stages

An SSH session is built in three layered stages. Understanding them clarifies why the connection is both private and trustworthy.

1. Encrypting the channel

The transport layer runs first. The client and server perform a key exchange (commonly using Diffie-Hellman or its elliptic-curve variant) to agree on a shared secret without ever sending that secret across the network. From it they derive symmetric session keys, then switch to fast symmetric ciphers such as AES to encrypt the rest of the conversation. The same step negotiates a message authentication code (MAC) so each packet's integrity is verified, defeating tampering.

2. Verifying the server

During the same handshake, the server presents its host key, a long-lived public key that identifies the machine. Your client checks this key against its known_hosts file. On the first connection there is nothing to compare against, so SSH shows you the key fingerprint and asks you to confirm. This trust-on-first-use model is why a changed host key later triggers a loud warning: it can mean the server was rebuilt, or that someone is impersonating it in a man-in-the-middle attack.

3. Authenticating the client

After the encrypted, server-verified channel exists, SSH proves who the client is. The protocol supports several methods. Password authentication sends your account password through the already-encrypted tunnel. Public-key authentication is the preferred method: you generate a key pair, place the public key in the server's authorized_keys file, and keep the private key on your own machine. The server sends a challenge, the client signs it with the private key, and the server verifies the signature with the stored public key, so the secret itself never travels anywhere.

SSH Keys: The Recommended Way to Authenticate

Public-key authentication is more secure and more convenient than passwords. You can protect the private key with a passphrase and an agent so you type it once per session, and you can revoke access by removing a single line from authorized_keys.

Generate a key pair with ssh-keygen. Modern guidance favors the Ed25519 algorithm for new keys; RSA with a 3072-bit or larger modulus remains a solid, broadly compatible choice, and you can produce one in the browser with the RSA Key Generator for testing.

ssh-keygen -t ed25519 -C "you@example.com"

This writes a private key (for example ~/.ssh/id_ed25519) and a matching public key ending in .pub. Copy the public key to a server with ssh-copy-id user@server, which appends it to ~/.ssh/authorized_keys. Related public-key infrastructure uses the same building blocks: a certificate signing request, which you can scaffold with the CSR Command Generator, relies on a key pair in exactly this way.

The single most important rule: never share or commit the private key. Treat its file permissions strictly (chmod 600), back it up securely, and use a passphrase. If a private key leaks, anyone who has it can log in as you until you remove the corresponding public key from every server.

What Else SSH Can Do

Beyond an interactive shell, SSH carries other useful traffic over the same secured connection.

SCP and SFTP transfer files. The scp command copies files using the SSH transport, while SFTP is a richer file-transfer subsystem supporting directory listings, resumes, and permissions, exposed by clients like sftp and many graphical file managers.

Port forwarding (tunneling) relays arbitrary TCP connections through the encrypted channel. Local forwarding maps a port on your machine to a service reachable from the server, useful for reaching a database that only listens on the remote host's localhost. Remote forwarding does the reverse, and dynamic forwarding turns SSH into a lightweight SOCKS proxy.

A config file at ~/.ssh/config lets you save per-host settings such as hostname, user, port, and identity file, so ssh myserver expands to a full command. This avoids long invocations and keeps options consistent. The SSH Config Builder generates a valid block for you.

Host myserver
    HostName 203.0.113.10
    User deploy
    Port 2222
    IdentityFile ~/.ssh/id_ed25519

Security Practices That Matter

A handful of habits prevent most real-world incidents. Disable password authentication once keys work, so brute-force login attempts cannot succeed. Disable direct root login and use a normal account with sudo. Keep OpenSSH updated to receive security fixes. Always verify a new host key's fingerprint out of band rather than blindly accepting it, since accepting a forged key undermines the entire model. Avoid agent forwarding to servers you do not fully trust, because it exposes your local keys to that host.

Because authentication often involves comparing fingerprints and hashes, tools like the Hash Generator and the SSL Certificate Decoder are handy companions when you are inspecting keys, certificates, and the broader TLS world that shares SSH's cryptographic primitives.

Where You Will Encounter SSH

SSH underpins a large fraction of day-to-day software work. It is how developers reach production and staging servers, how Git authenticates pushes and pulls over the ssh:// transport, how configuration-management and deployment tools execute remote commands, and how engineers tunnel into otherwise private services. Because it is secure by default and available almost everywhere, it has become the standard way to administer machines you cannot physically touch.

Frequently Asked Questions