- 加密协议（cryptographic protocols ）：其他网络协议（HTTP）支持数据加密传输。
FTPS = FTP + SSL （FTP添加SSL加密协议支持）
SFTP = SSH File Transfer Protocol （基于SSH的文件传输协议）
Secure FTP(FTP over SSH) = SSH + FTP（FTP使用SSH隧道传输）
What is the difference between SSH and SSL?
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.
Links for more information:
Snailbook, SSH and SSL differences
What’s the difference between SSH and SSL/TLS?
SSL stands for “Secure Sockets Layer;” TLS, for “Transport Layer Security.” SSL was developed by Netscape for use in securing HTTP. That is still its principal use, although there is nothing specific to HTTP about SSL. When a browser accesses a URL which begins with “https”, it speaks HTTP over an SSL connection. TLS is the name of the IETF protocol standard that grew out of SSL 3.0, and is documented by RFC 2246. We will use the term “TLS.”
TLS has goals and features similar to those of the SSH Transport and User Authentication protocols. It provides a single, full-duplex byte stream to clients, with cryptographically assured privacy and integrity, and optional authentication. It differs from SSH in the following principal ways:
* TLS server authentication is optional: the protocol supports fully anonymous operation, in which neither side is authenticated. Such connections are inherently vulnerable to man-in-the-middle attacks. In SSH-TRANS, server authentication is mandatory, which protects against such attacks. Of course, it is always possible for a client to skip the step of verifying that the public key supplied by the server actually belongs to the entity the client intended to contact (e.g. using the /etc/ssh_known_hosts file). However, SSH-TRANS at least demands going through the motions.
* Both client and server authentication are done with X.509 public-key certificates. This makes TLS a bit more cumbersome to use than SSH in practice, since it requires a functioning public-key infrastructure (PKI) to be in place, and certificates are more complicated things to generate and manage than SSH keys. However, a PKI system provides scalable key management for your trouble, which SSH currently lacks.
* TLS does not provide the range of client authentication options that SSH does; public-key is the only option.
* TLS does not have the extra features provided by the other SSH component: the SSH Connection Protocol (SSH-CONN). SSH-CONN uses the underlying SSH-TRANS connection to provide muliple logical data channels to the application, as well as support for remote program execution, terminal management, tunnelled TCP connections, flow control, etc.