SSH
Secure Shell
An encrypted network protocol on TCP port 22 that provides secure remote login, command execution, file transfer, and port forwarding — replacing insecure predecessors like Telnet and rsh as the universal standard for remote server administration.
SSH replaced Telnet in the late 1990s by wrapping the remote shell in strong encryption. Every byte of an SSH session — your commands, the server's output, passwords — is encrypted using negotiated algorithms (commonly AES-256 for symmetric encryption, Ed25519 or RSA for key authentication). The client authenticates the server by its host key fingerprint, preventing man-in-the-middle attacks. SSH runs on TCP port 22 and is available on every Unix/Linux system and macOS by default; Windows includes it natively since Windows 10.
Authentication methods
Password authentication is the simplest method: you type a password, SSH transmits it encrypted to the server, and the server validates it against its user database. It works without any setup beyond having an account, but it is vulnerable to brute-force attacks if weak passwords are allowed — automated bots attempt millions of combinations against port 22 every day. Public key authentication is the standard hardened approach: you generate a key pair locally, place the public key in ~/.ssh/authorized_keys on the server, and keep the private key on your client machine. Authentication works by the server challenging the client to prove it holds the private key — the private key never leaves your machine. Certificate-based authentication extends key auth for fleet management: a CA signs user and host keys, and servers are configured to trust that CA rather than individual authorized_keys entries. This scales to thousands of servers without per-server key distribution.
SSH key types compared
| Key Type | Recommended Size | Status | Notes |
|---|---|---|---|
| RSA | 4096 bits | Still acceptable | Widely supported; larger keys are slower to generate but fine in practice |
| Ed25519 | Fixed (256-bit) | Preferred | Smaller key files, faster operations, same security level as RSA-3072+ |
| ECDSA | 256 or 384 bits | Acceptable | Faster than RSA; some concern about NIST curve implementations |
| DSA | 1024 bits only | Deprecated | Removed from modern OpenSSH; do not use |
Connection setup and host key verification
When you connect to a new server, SSH performs a key exchange using an algorithm negotiated in the client's and server's KEX lists (typically curve25519-sha256 or ecdh-sha2-nistp256). The server presents its host key as proof of identity. The first time you connect to a host, SSH uses Trust On First Use (TOFU) — it stores the fingerprint in ~/.ssh/known_hosts and asks you to verify it matches what you expected. On subsequent connections, SSH checks the stored fingerprint against what the server presents. A mismatch triggers a prominent warning and refuses connection — this is the mechanism that protects against a server being swapped, rebuilt with a new key, or impersonated by a MITM attacker. Always verify the fingerprint out-of-band (e.g., from the cloud console) when connecting to a new server rather than blindly accepting.
SSH tunneling use cases
Local forwarding (-L) binds a port on your local machine and forwards connections through the SSH server to a remote destination. Example: ssh -L 8080:internal-server:80 user@jumphost lets you access http://localhost:8080 locally while the traffic actually reaches internal-server:80 through the SSH tunnel — useful for reaching admin dashboards, databases, or internal services that are not exposed to the internet. Remote forwarding (-R) does the reverse: it opens a port on the SSH server and forwards connections back to your local machine. Example: ssh -R 9090:localhost:3000 user@public-server exposes your local development server on the public server's port 9090 — useful for demos or webhooks that need to reach a local service. Dynamic forwarding (-D) creates a SOCKS5 proxy on a local port, routing all configured application traffic through the SSH server: ssh -D 1080 user@host, then configure your browser's SOCKS proxy to localhost:1080.
SSH config file
The ~/.ssh/config file lets you define per-host settings so you never type a long command again. A well-organized config file also prevents mistakes with the wrong key or wrong username.
| Directive | Example Value | Purpose |
|---|---|---|
| Host | prod | The alias used in ssh prod |
| HostName | server.example.com | Actual hostname or IP |
| User | deploy | Remote username |
| Port | 2222 | Non-standard port |
| IdentityFile | ~/.ssh/id_ed25519 | Which private key to use |
| ServerAliveInterval | 60 | Send keepalive every 60 seconds to prevent idle disconnects |
| ControlMaster | auto | Reuse existing connection for new sessions (connection multiplexing) |
| ControlPersist | 10m | Keep master connection alive 10 minutes after last session |
SSH hardening
On internet-facing servers, the default SSH configuration is rarely secure enough. Key hardening steps in /etc/ssh/sshd_config: set PasswordAuthentication no to eliminate brute-force attack surface; set PermitRootLogin no to prevent direct root login (use sudo from a named account); use AllowUsers or AllowGroups to whitelist exactly who can log in. Deploy fail2ban or sshguard to automatically block IPs after repeated failed authentication attempts. Running SSH on a non-standard port (e.g., 2222) reduces automated scan noise but is security through obscurity — not a real control. Firewall rules that restrict source IPs to known office or VPN ranges are a far stronger measure.
SSH agent forwarding risks
SSH agent forwarding (ForwardAgent yes) allows the SSH agent on your local machine to be used by the remote server — so from a jump host you can SSH further to internal servers using your local keys. The risk: anyone with root access on the intermediate server can use your forwarded agent to impersonate you to any server your key can reach. Never enable agent forwarding to untrusted servers. Use -J (ProxyJump) instead — it routes the SSH connection through the jump host without exposing your agent to it.
Frequently Asked Questions
What is the difference between SSH password and key-based authentication?
Password auth transmits your password (encrypted) — vulnerable to brute force. Key auth uses an asymmetric key pair: the public key on the server, the private key never leaving your machine. Key auth is far more secure; disabling password auth entirely is standard hardening for internet-facing servers.
What is SSH port forwarding?
Encrypted tunnels through SSH. Local (-L) forwards a local port to a remote destination — access a firewall-protected database locally. Remote (-R) exposes a local port on the remote server. Dynamic (-D) creates a SOCKS5 proxy routing all app traffic through the SSH server.
Why is SSH on port 22 a security risk and should I change it?
Port 22 is constantly scanned by bots. Moving to a non-standard port reduces automated noise. Real security comes from key-only auth (PasswordAuthentication no), disabling root login, and fail2ban. Changing the port is a minor noise reducer, not a security control.