Difference between SSH and SSL, especially in term

Question

Apart from enhanced authentication options offered by SSH, is there any difference between basic working of SSH and SSL protocols ?

I am asking since we can use SFTP or FTP over SSL, both would require authentication.

Answer 1

What is the difference between SSH and SSL and why would we care?

SSL stands for "Secure Sockets Layer". We care because it enables browsers to transmit data to and from a web server in a secure cryptographic way to make life hard for third party spies monitoring all internet traffic.

SSH stands for "Secure Shell". We care because it enables a networked computer 1 to provide access to a shell on networked computer 2. The user can have a level of confidence that spies listening to the insecure channel cannot decrypt data sent between the networked computers.

SSL and SSH both have to do with providing a system to encrypt and decrypt data over an insecure channel.

When a browser visits a URL which begins with "https://", the browser speaks HTTP over an SSL connection.

SSL enabled Web Servers (for example Apache HTTP Server) can be configured to use SSL to become a "secure web server". A website served up by a secure web server will cause users to access the URL through the "https://" protocol instead of "http://". With the https protocol the users can have a level of confidence that third party spies monitoring the internet channel will only receive encrypted content.

SSL is a Protocol that could be implemented in the 6th layer (Presentation layer) of the OSI Model.

SSH has its own transport protocol independent from SSL, so that means SSH DOES NOT use SSL under the hood.

Cryptographically, both Secure Shell and Secure sockets Layer are both equally secure.

An SSL Termination Proxy can handle incoming SSL connections, decrypting the SSL and passing on the unencrypted request to other servers.

SSL lets you use a PKI (public-key infrastructure) via signed certificates. With SSH you have to exchange the key fingerprints manually through another protocol like ftp or carrier pigeon.

Answer 2

First of all, TLS server authentication is optional since its protocol supports fully anonymous server authentication. In SSH this is mandatory.

TLS uses X.509 certificates for client and server authentication, which would require some sort of PKI. SSH does not scale in this point but offers a wider range of authentication methods: password, public key, etc.

Another difference is that SSH allows multiple connections and supports remote program execution, terminal management, TCP tunneling and so on.

Answer 3

The main difference is that SSL lets you use a PKI (via signed certificates). In SSH you have to exchange the key fingerprints out-of-band. But you might want to do without a PKI anyway, in which case it's a tie.

For a nice explanation, see http://www.snailbook.com/faq/ssl.auto.html

Answer 4

Cryptographically they are both equally secure (given that same ciphers are used). Other than that they are entirely different protocols...

Answer 5

SSH and SSL are similar protocols that both use most of the same cryptographic primitives under the hood, so they are both as secure as each other. One advantage of SSH is that using key-pair authentication is actually quite easy to do, and built right into the protocol.

With SSL it's a bit of a mess involving CA certificates and other things. After you have the PKI in place you also need to configure your services to use the PKI for authentication instead of its internal password database; this is a nightmare on some services and a piece of cake on others. It also means you need to go to the hassle of signing all of your user's keys so they can log in with them.

Most competent users can grok SSH keys in no time but it takes a bit longer to get their heads around SSL keys (the extra CA certs and key certs confused me when I first discovered it).

Pick what's supportable. SSH+SFTP is great for Unix people, but FTP over SSL is probably easier to do if your users are Windows-based and are pretty clueless about anything other than Internet Exploiter (and you don't mind risking that your users will choose insecure passwords).