SSH vs SSL/TLS

Secure shell vs secure sockets

SSH and SSL/TLS are both cryptographic protocols that provide secure communication, but they serve different purposes. SSH is designed for secure remote access and command execution. SSL/TLS is designed for securing arbitrary network connections, most famously HTTPS web traffic.

SSH

SSH (Secure Shell) is a cryptographic network protocol designed for secure remote access to machines. Created in 1995 by Tatu Ylonen as a replacement for insecure protocols like Telnet and rlogin, SSH provides encrypted terminal sessions, file transfer (SCP/SFTP), and port forwarding/tunneling. SSH typically uses public key authentication — you generate a key pair, place the public key on the server, and authenticate with the private key (no password needed). SSH runs on port 22 by default and is the standard tool for server administration, Git operations (git@github.com), and creating secure tunnels. The most common implementation is OpenSSH, included in every Linux/macOS system and now Windows.

SSL/TLS

SSL/TLS (Secure Sockets Layer / Transport Layer Security) is a cryptographic protocol that provides encrypted communication between two networked applications. SSL was created by Netscape in the 1990s and has been succeeded by TLS (the current standard is TLS 1.3). TLS works as a layer below application protocols — it encrypts the connection, and the application protocol (HTTP, SMTP, IMAP, FTP) runs on top. The result is HTTPS, SMTPS, IMAPS, and FTPS. TLS uses certificates issued by Certificate Authorities (CAs) to authenticate servers. The TLS handshake negotiates encryption algorithms, verifies the server's certificate, and establishes an encrypted channel. TLS is the backbone of secure internet communication.

Key Differences

- **Purpose**: SSH provides secure remote access (login, file transfer, tunneling). SSL/TLS secures arbitrary network connections (web, email, any TCP protocol). - **Authentication model**: SSH uses public key pairs or passwords. TLS uses CA-signed certificates for server authentication (and optionally client certificates). - **Trust model**: SSH uses trust-on-first-use (TOFU) — you manually verify the server's fingerprint. TLS uses a hierarchy of Certificate Authorities. - **Typical use**: SSH for sysadmin, Git, and tunneling. TLS for HTTPS, secure email, and API communication. - **Port**: SSH defaults to port 22. TLS/HTTPS defaults to port 443. - **Layer**: Both operate at the transport/application layer, but TLS is designed as a generic wrapper while SSH is a complete application protocol.

When to Use Each

**Use SSH** for remote server administration, deploying code, transferring files between machines, Git repository access, and creating encrypted tunnels to access services behind firewalls. **Use TLS** for securing web traffic (HTTPS), email transmission, API communication, database connections, and any client-server protocol where you need encrypted transport. If you're building a web service, you're using TLS. If you're managing the server running that service, you're using SSH.

Analogy

**SSH** is like having a secure, private phone line directly to someone's office — you can give them commands, send them files, or ask them to relay messages to other offices on your behalf (tunneling). You verify their identity by recognizing their voice. **SSL/TLS** is like a secure mail courier service — it encrypts and seals any package (web page, email, API response) for delivery. The courier's uniform and badge (certificate) are verified by a trusted authority, and the package is tamper-proof in transit.