要想以通俗易懂的方式介绍SSL和SSH的区别，并不是一件轻松的事。下文至结论之前的内容翻译自国外的一篇文章，并做了少许改动；原文附在最后面，相信看完之后，您会对两者之间的区别有了较为清晰的理解。

一、基本概念

SSH 为 Secure Shell 的缩写，由 IETF 的网络小组（Network Working Group）所制定；SSH 为建立在应用层基础上的安全协议。SSH 是较可靠，专为远程登录会话和其他网络服务提供安全性的协议。利用 SSH 协议可以有效防止远程管理过程中的信息泄露问题。SSH最初是UNIX系统上的一个程序，后来又迅速扩展到其他操作平台。SSH在正确使用时可弥补网络中的漏洞。SSH客户端适用于多种平台。几乎所有UNIX平台—包括HP-UX、Linux、AIX、Solaris、Digital UNIX、Irix，以及其他平台，都可运行SSH。

SSL(Secure Sockets Layer 安全套接字协议),及其继任者传输层安全（Transport Layer Security，TLS）是为网络通信提供安全及数据完整性的一种安全协议。TLS与SSL在传输层与应用层之间对网络连接进行加密。

二、两者区别

SSH (secure shell) 和 SSL(secure socket layer) 都能用于网络通讯加密，两者有相同之处，也有不同之处，本文试着以易于理解的方式来解释两者的不同。

SSL的设计初衷是为了确保网络会话的安全，而SSH是设计初衷为了代替 telnet 和 FTP。当然，它们都能用来做许多其它的事情。

SSL有很多用途，HTTPS的实现就是在HTTP基础上加入了SSL的支持。它也可以用在POP3,SMTP,IMAP以及几乎所有支持TCP协议的应用程序。对于创建网络应用程序的大多数程序员，只需要简单的在应用程序中加入SSL实现，即可通过TCP在网络上进行通信时提供加密。

SSH是一种瑞士军刀，设计为做许多不同的事情，其中​​大部分都围绕在主机之间建立安全的隧道。 SSH的一些实现依赖于SSL库 - 这是因为SSH和SSL使用许多相同的加密算法。

SSH不是基于SSL的，而HTTPS是基于SSL的。SSH比SSL做得更多，它们之间不能通信–这是两个不同的协议，但是在如何实现类似的目标有相同之处。

SSL本身不能做任何事情，只是规定如何握手和加密（数据），您需要一个应用程序来驱动SSL以完成真正的工作。

SSH本身做了很多有用的事情，允许用户执行真正的工作。 SSH主要的两个用处是控制台登录（telnet替换）和安全文件传输（ftp替换），但您也能给其他应用程序打通一个SSH隧道，允许用户通过它运行HTTP，FTP，POP3和其它应用。

如果没有来自应用程序的通信，SSL什么都不做。即使没有来自应用程序的通信，SSH也会在两台主机之间创建一个加密隧道，这样可以通过交互式登录shell，文件传输等方式完成实际工作。

三、结论：

SSL和SSH只是看上去和听起来有些相似，在理解过程中也会产生一些混淆，但实际是完全两个不同的协议和事物：

• 从某种意义上说，SSL只是一个协议，可以在任何支持TCP/IP协议的程序中使用它；这需要由程序员来加入相应支持（当然并不难）；
• SSH则是一套完整的软件体系，既包括了协议，也包括了实现；当然，在底层实现上，SSH可以使用SSL协议，也可以不使用；
• 使用SSH隧道进行通信，并不需要对所有的软件和应用程序做出改动，只需要在两个主机之间建立一个安全隧道，后续的通信数据都会被加密；
• SSL和SSH共同使用了一些相同加密算法、开源模块，且功能有相似之处，难免有时让人感到困惑。

附原文：

SSH (Secure Shell) and SSL (Secure Sockets Layer) can both be used to secure communications across the Internet. This page tries to explain the differences between the two in easily understood terms.

SSL was designed to secure web sessions; it can do more, but that’s the original intent.

SSH was designed to replace telnet and FTP; it can do more, but that’s the original intent.

SSL is a drop-in with a number of uses. It front-ends HTTP to give you HTTPS. It can also do this for POP3, SMTP, IMAP, and just about any other well-behaved TCP application. It’s real easy for most programmers who are creating network applications from scratch to just grab an SSL implementation and bundle it with their app to provide encryption when communicating across the network via TCP. Check out: stunnel.org.

SSH is a swiss-army-knife designed to do a lot of different things, most of which revolve around setting up a secure tunnel between hosts. Some implementations of SSH rely on SSL libraries - this is because SSH and SSL use many of the same encryption algorithms (i.e. TripleDES).

SSH is not based on SSL in the sense that HTTPS is based on SSL. SSH does much more than SSL, and they don’t talk to each other - the two are different protocols, but have some overlap in how they accomplish similiar goals.

SSL by itself gives you nothing - just a handshake and encryption. You need an application to drive SSL to get real work done.

SSH by itself does a whole lot of useful stuff that allows users to perform real work. Two aspects of SSH are the console login (telnet replacement) and secure file transfers (ftp replacement), but you also get an ability to tunnel (secure) additional applications, enabling a user to run HTTP, FTP, POP3, and just about anything else THROUGH an SSH tunnel.

Without interesting traffic from an application, SSL does nothing. Without interesting traffic from an application, SSH brings up an encrypted tunnel between two hosts which allows you to get real work done through an interactive login shell, file transfers, etc.

Last comment: HTTPS does not extend SSL, it uses SSL to do HTTP securely. SSH does much more than SSL, and you can tunnel HTTPS through it! Just because both SSL and SSH can do TripleDES doesn’t mean one is based on the other.