What SSH Does
SSH provides an encrypted channel between two computers over an untrusted network. Its three primary capabilities are remote terminal access, file transfer, and port forwarding. When you connect to a server via SSH, every keystroke you type and every line of output you receive travels inside an encrypted tunnel — an observer on the network sees only encrypted ciphertext, not your commands or passwords.
The protocol was designed as a drop-in replacement for Telnet, rsh, and rcp — older Unix remote access tools that transmitted everything in plaintext. SSH addressed all of their security weaknesses at once: it encrypts the session, verifies the identity of the remote server (preventing man-in-the-middle attacks), and supports strong client authentication through public-key cryptography.
SSH-1 vs SSH-2
SSH version 1 was the original protocol released by Tatu Ylönen in 1995. It contained several cryptographic weaknesses, including a vulnerability to insertion attacks against the data stream. SSH-2 was published as an IETF standard (RFC 4251–4256) in 2006 and addressed all known SSH-1 weaknesses through a redesigned handshake and message authentication codes. SSH-1 is now deprecated and disabled in virtually all modern SSH implementations. If you encounter an SSH server that only supports protocol version 1, treat it as an unpatched legacy system that requires immediate attention.
How the SSH Handshake Works
When your SSH client connects to a server, the two parties negotiate the connection parameters before any authentication occurs. The server sends its host key — a long-term public key that identifies this specific server. Your client checks the key against its ~/.ssh/known_hosts file. If the key is new, your client asks you to verify it manually and stores it for future connections. If the key changed unexpectedly, your client warns you of a potential man-in-the-middle attack.
After host verification, the client and server perform a Diffie-Hellman key exchange to derive a shared session key. This key is used to encrypt the rest of the session using a symmetric cipher — typically AES-256-GCM or ChaCha20-Poly1305 in modern implementations. The entire exchange uses forward secrecy: even if a private key is compromised later, recorded past sessions cannot be decrypted.
Password vs Public-Key Authentication
SSH supports several authentication methods. Password authentication is the simplest — you enter your account password, which is transmitted securely inside the already-encrypted channel. It is convenient but vulnerable to brute-force attacks if the server is internet-facing.
Public-key authentication is more secure and is the recommended method for any production server. You generate a key pair with ssh-keygen. The private key stays on your machine, protected by an optional passphrase. The public key is placed in ~/.ssh/authorized_keys on the remote server. When you connect, the server challenges your client to prove possession of the matching private key. The challenge-response exchange never transmits the private key itself. An attacker who captures network traffic cannot reconstruct your private key from what they observe.
The SSH Config File
The file ~/.ssh/config lets you define aliases and per-host options so you do not need to type long connection strings every time. A typical entry looks like:
Host myserver HostName 203.0.113.42 User alice IdentityFile ~/.ssh/id_ed25519_myserver Port 2222
After writing this, you can connect with just ssh myserver. The config file also lets you set global defaults — such as ServerAliveInterval 60 to prevent idle connections from timing out — and control per-host options like compression, forwarding, and cipher preferences.
SSH Tunneling and Port Forwarding
SSH can forward TCP connections through its encrypted channel, a feature called port forwarding or tunneling. Local port forwarding (ssh -L 8080:internal-host:80 user@gateway) makes a remote service appear on a local port. Remote port forwarding (ssh -R 9090:localhost:3000 user@server) exposes a local service on a port of the remote server. Dynamic port forwarding (ssh -D 1080 user@server) creates a SOCKS5 proxy, letting you route all browser traffic through the remote server.
Tunneling is widely used to securely access databases, Redis instances, internal dashboards, and other services that listen only on loopback or private interfaces. It eliminates the need to open additional firewall ports because everything travels over the single SSH connection on port 22.
Common SSH Commands
The core commands you will use regularly are: ssh user@host to open a terminal session; ssh-keygen -t ed25519 to generate a new key pair; ssh-copy-id user@host to install your public key on a remote server; scp file user@host:/path to copy a single file; and sftp user@host to open an interactive file transfer session. The ssh-agent daemon holds your decrypted private key in memory so you do not need to enter your passphrase for every connection. ssh-add ~/.ssh/id_ed25519 loads a key into the agent. Agent forwarding (-A flag) passes your agent credentials to intermediate servers so you can hop from one server to another without copying your private key.
SSH Authentication Methods
| Method | Security Level | How It Works | Setup Required | Best Use Case |
|---|---|---|---|---|
| Password | Low–Medium | Password sent inside encrypted channel | None (uses existing OS password) | Quick access to non-critical internal hosts |
| Public key (RSA 4096) | High | Challenge signed with private key | Generate key pair, install public key on server | Production servers, automated scripts |
| Public key (Ed25519) | Very High | Challenge signed with Ed25519 private key | Generate key pair, install public key on server | Preferred for all new deployments |
| Certificate-based | Very High | SSH CA signs user/host certificates | SSH CA infrastructure, signed certificates | Large organizations managing many servers |
| FIDO2/Hardware key | Highest | Private key stored on hardware token | FIDO2 key, ssh-keygen -t ecdsa-sk | High-security environments, privileged access |
Hardening SSH
A default SSH installation on a public IP will receive automated brute-force attempts within minutes. The most important hardening steps are: disable password authentication (PasswordAuthentication no in /etc/ssh/sshd_config); disable root login (PermitRootLogin no); restrict which users can connect (AllowUsers alice bob); move to a non-standard port; and install fail2ban to block IPs after repeated failed attempts. Keeping the SSH server package updated patches cryptographic vulnerabilities before they can be exploited. Consider an SSH bastion host (jump host) for accessing internal servers — all SSH traffic passes through a single, hardened gateway rather than exposing every internal server directly.
Frequently Asked Questions
What port does SSH use?
SSH uses TCP port 22 by default. This port is well-known and frequently targeted by automated scanners and brute-force bots. A common hardening practice is to move SSH to a non-standard port (such as 2222 or a high-numbered port above 1024) to reduce log noise from automated attacks. This is security through obscurity and should be combined with other controls like key-based authentication and fail2ban.
How do SSH keys work?
SSH uses asymmetric cryptography. You generate a key pair: a private key that stays on your local machine and a public key that is placed on the remote server in the ~/.ssh/authorized_keys file. When you connect, the server sends a challenge that can only be answered correctly using the matching private key. Your client signs the challenge with your private key, the server verifies the signature using your public key, and access is granted without ever transmitting the private key.
Is SSH encrypted?
Yes, SSH encrypts all traffic including the initial authentication exchange, all commands, and all output. The session is protected by a symmetric session key negotiated during the handshake using Diffie-Hellman key exchange. Common symmetric ciphers used include AES-128-CTR, AES-256-CTR, AES-256-GCM, and ChaCha20-Poly1305. This is a fundamental difference from Telnet, which transmits everything in plaintext.
What is the difference between SSH and SSL/TLS?
SSH and TLS are both cryptographic protocols that establish encrypted channels, but they serve different purposes. TLS secures application-layer protocols like HTTPS, SMTP, and IMAP — it provides a transport security layer that other protocols sit on top of. SSH is a complete remote access protocol that includes its own authentication, terminal emulation, and file transfer capabilities. SSH is not built on TLS; they are independent protocols with their own handshake mechanisms and cipher suites.
How do I generate an SSH key pair?
Run ssh-keygen -t ed25519 -C "your-comment" on your local machine. This creates two files: ~/.ssh/id_ed25519 (private key — never share this) and ~/.ssh/id_ed25519.pub (public key). Copy the public key to the remote server using ssh-copy-id user@host, which appends it to ~/.ssh/authorized_keys. Ed25519 keys are preferred over RSA for new deployments because they are shorter, faster, and considered more secure. For RSA compatibility, use ssh-keygen -t rsa -b 4096.
Can SSH be used for more than remote terminal access?
Yes. SSH supports SFTP and SCP for encrypted file transfer, port forwarding (local, remote, and dynamic) for tunneling other protocols through the encrypted channel, X11 forwarding for running graphical applications remotely, and SOCKS proxy mode (-D flag) for routing all browser traffic through a remote server. SSH tunneling is commonly used to securely access databases, internal web interfaces, and other services that should not be directly exposed to the internet.