SSL vs SSH: what is the difference?

SSL, today TLS, and SSH both encrypt connections, but they protect different things. TLS secures connections between programs, above all browsers and websites, and proves the server's identity with a certificate issued by an authority. SSH gives an administrator a secure remote shell and file transfer, and identifies servers by keys that users accept on first connection. They are not competing choices for the same job. This page compares them and shows where each is used. It is part of the glossary.

At a glance

What they have in common

Both set up an encrypted channel the same way at heart. The two sides agree on algorithms, derive shared keys with a Diffie-Hellman exchange, authenticate the server, and then encrypt and integrity-protect every message with a symmetric cipher such as AES-GCM or ChaCha20-Poly1305. Both have dropped old algorithms over the years, and both protect against eavesdropping and tampering on the network.

"SSL" itself is retired: every SSL version is deprecated and what runs today is TLS. The name survives in everyday use, as on SSL vs TLS.

How they verify the server

This is the real difference, and it decides where each fits.

• TLS uses certificate authorities. A server presents an X.509 certificate that a certificate authority signed after checking that the requester controls the name. The client trusts it because the chain ends at a root certificate in its trust store. A browser can therefore safely connect to a site it has never seen, which is what the web needs.

• SSH usually trusts on first use. The first time you connect, SSH shows the server's key fingerprint and asks whether to accept it. If you do, the key is stored in known_hosts, and SSH warns loudly if it ever changes. This works for a small set of servers an administrator knows; it would not work for millions of websites visited once. Large organisations can add SSH certificates signed by their own SSH authority, a separate format from X.509.

Authorities are watched in public as well: certificate transparency records the certificates they issue in public logs, so one issued for your domain without your request can be found. Some apps go further with certificate pinning, accepting only a specific certificate or key for a server, which is close to how SSH treats a host key it has remembered.

How they verify the user

TLS on the web usually identifies only the server; the website then signs users in with its own login. Mutual TLS adds a client certificate where a system must identify the client too; see mTLS.

SSH always identifies the user, by password or, preferably, by a key pair whose public half is stored on the server in authorized_keys.

Where each is used

• TLS: HTTPS websites and APIs, mail between clients and servers and between servers, database connections, VPNs built on TLS, and DNS over TLS. The ports differ by protocol, as on port 443.

• SSH: logging in to servers and network devices, running commands remotely, copying files with SCP or SFTP, Git over SSH, and tunnels that forward other traffic through an SSH connection.

• SFTP and FTPS are a common point of confusion. SFTP is file transfer over SSH, usually on port 22. FTPS is the old FTP protocol wrapped in TLS, on ports 990 or 21. They are different protocols that solve the same problem.

Which to use

Choose by the job, not by the encryption.

• Serving a website or an API: TLS. Browsers and clients only speak HTTPS, and they need a certificate from a trusted authority.

• Administering a server: SSH, with key-based login and password login turned off.

• Transferring files: SFTP for administrators and automated jobs between systems you control; HTTPS uploads for anything public-facing.

Running both on one server is normal: HTTPS on 443 for visitors, SSH on 22 for the people who maintain it.

FAQ