Secure FTP, FTP/SSL, SFTP, FTPS, FTP, SCP... What's the difference?

 

Protocol Type
Specifies the protocol type used for publising the report results to FTP.

• FTP (Standard File Transfer Protocol)
  Files are transferred in a non-secure (plain text) style.
• SFTP using SSH2 (Secure Shell)
  SFTP (Secure FTP) is a component of Secure Shell and is supported by most Unix servers running SSH2. Ask your server administrator about availability.
• SCP (Secure Copy)
  This is a means of securely transferring computer files between a local and a remote host or between two remote hosts, using the Secure Shell (SSH) protocol. If this type is selected, you will not be able to create folder to the FTP server.
• FTP with TLS/SSL (Explicit)
  Explicit connection type of FTP security with TLS/SSL.
• FTP with TLS/SSL (Implicit)
  Implicit connection type of TP security with TLS/SSL.

There are several different secure file transfer protocols that are, unfortunately, named in a very confusing way that often makes it difficult to distinguish one from another. The aim of this page is to provide some guidelines to make it easier to determine which is which.

Communication protocols

Basically, there are the following file transfer protocols around:

FTP – the plain old FTP protocol that has been around since 1970s. The acronym stands for "File Transfer Protocol". It usually runs over TCP port 21.

SFTP – another, completely different file transfer protocol that has nothing to do with FTP. SFTP runs over an SSH session, usually on TCP port 22. It has been around since late 1990s. The acronym actually stands for "SSH File Transfer Protocol".

SCP – a variant of BSD rcp utility that transfers files over SSH session. The SCP protocol has been mostly superseded by the more comprehensive SFTP protocol and some implementations of the "scp" utility actually use SFTP instead.

Secure communication layers

Additionally, there are the following two secure communication layers:

SSH – a protocol that allows establishing a secure channel between the local and the remote computer. Server as an underlying channel for associated protocols such as secure shell, port forwarding, SFTP or SCP. While it is possible to run the (slightly modified) plain old FTP protocol over SSH, this is not very common, fortunately. File transfer over SSH is nearly always done using SFTP or SCP.

TLS – this is almost generally known primarily by its old name - SSL - and provides a way of securing otherwise unsecure protocols such as HTTP, SMTP, POP3 or FTP. Please note that SSL 3.1 is called TLS 1.0, and therefore TLS 1.0 is a newer version of the protocol than SSL 3.0, despite the lower version number. HTTP over SSL is often called HTTPS, and FTP over SSL is often called FTPS and has two variants, explicit (starts as an unencrypted FTP session and is secured on client request) and implicit (is secured right from the beginning and therefore needs a separate TCP port, usually 990). The implicit mode is deprecated, but still widely used.

Secure file transfer protocols, or fitting it all together

In an ideal world, the information above should be just enough. Unfortunately, this is not the case. The file transfer protocols are also referred to by other names, and even the names that only refer to a one single protocol are often mistakenly used for the wrong protocol by (understandably) confused authors.

FTP – should be only used for the plain old FTP protocol.

SFTP – should be only used for SFTP, the SSH file transfer protocol. However, people often shorten Secure FTP into SFTP - this is not correct, because the S in SFTP does not stand for Secure, but for SSH.

SFTP2 – this confusing name is used by some vendors to highligh the obvious fact that their SFTP protocol runs over SSH2. For all practical purposes, consider this to be a synonym of SFTP, because SSH1 has been deprecated for many years.

Secure FTP – this name is the most confusing, because it is used to refer to either of the two different protocols. Whenever this name is used, it is necessary to specify whether the SSH-based or SSL-based file transfer protocol is meant.

SSH FTP, FTP over SSH – fortunately, these names are not used very often. They usually refer to SFTP, the SSH file transfer protocol. Even though it is possible to run the (slightly modified) plain old FTP protocol over SSH, this is not very common.

FTP/SSL, FTP/TLS, FTP over SSL, FTP over TLS, FTPS – should be only used for FTP over TLS/SSL.

SFTP over SSL – although the SFTP protocol can utilize any underlying data stream, in practice SFTP over anything other that SSH is very rare. It is much more likely the term was used by mistake in place of either "SFTP over SSH" or "FTP over SSL".

SCP – should be only used for scp protocol/utility, a variant of BSD rcp. Some applications with SCP in its name now use SFTP by default instead - examples of this practice are WinSCP application and scp2 utility.

TFTP is yet another file transfer protocol different from any of above.

 

 

1. SFTP: SSH File Transfer Protocol
2. FTPS: FTP over SSL
3. FTP over SSH
<from wikipedia>

FTP over SSH (not SFTP) refers to the practice of tunneling a normal FTP session over an SSH connection.

Because FTP uses multiple TCP connections (unusual for a TCP/IP protocol that is still in use), it is particularly difficult to tunnel over SSH. With many SSH clients, attempting to set up a tunnel for the control channel (the initial client-to-server connection on port 21) will protect only that channel; when data is transferred, the FTP software at either end will set up new TCP connections (data channels), which bypass the SSH connection, and thus have no confidentiality, integrity protection, etc.

TPS vs. SFTP: What to Choose

原文： www.codeguru.com/csharp/.net/net_general/internet/article.php/c14329

File transfer over the network using FTP protocol (defined by RFC 959 and later additions) has its roots in 1980, when the first RFC for FTP protocol was published. FTP provides functions to upload, download, and delete files; create and delete directories; and read directory contents. Although FTP is very popular, it has certain disadvantages that make it harder to use. The major drawbacks are lack of the uniform format for directory listing (this problem has been partially solved by introducing the MLST command, but it's not supported by some servers) and the presence of the secondary connection (DATA connection). Security in FTP is provided by employing SSL/TLS protocol for channel encryption as defined in RFC 2228. The secured version of FTP is called FTPS.

In UNIX systems, another security standard has grown. It was the SSH family of protocols. The primary function of SSH was to secure remote shell access to UNIX systems. Later, SSH was extended with file transfer protocol—first SCP (in SSH 1.x), and then SFTP (in SSH2). Version 1 of the SSH protocol is outdated, unsecure, and generally not recommended for use. Consequently, SCP is not used anymore and SFTP gains popularity day by day.

The "SFTP" abbreviation is often mistakenly used to specify some kind of Secure FTP, by which people most often mean FTPS. Another (similar) mistake is that SFTP is thought to be some kind of FTP over SSL. In fact, SFTP is an abbreviation of "SSH File Transfer Protocol." This is not FTP over SSL and not FTP over SSH (which is also technically possible, but very rare).

SFTP is a binary protocol, the latest version of which is standardized in RFC 4253. All commands (requests) are packed to binary messages and sent to the server, which replies with binary reply packets. In later versions, SFTP has been extended to provide not just file upload/download operations, but also some file-system operations, such as file lock, symbolic link, creation, and so forth.

Both FTPS and SFTP use a combination of an asymmetric algorithm (RSA, DSA), a symmetric algorithm (DES/3DES, AES, Twhofish and so on), and a key-exchange algorithm. For authentication, FTPS (or, to be more precise, SSL/TLS protocol under FTP) uses X.509 certificates, whereas SFTP (SSH protocol) uses SSH keys.

X.509 certificates include the public key and certain information about the certificate owner. This information lets the other side verify the integrity of the certificate itself and authenticity of the certificate owner. Verification can be done both by computer and to some extent by the human. An X.509 certificate has an associated private key that is usually stored separately from the certificate for security reasons.

A SSH key contains only a public key (the associated private key is stored separately). It doesn't contain any information about the owner of the key. Neither does it contain information that lets one reliably validate the integrity and authenticity. Some SSH software implementations use X.509 certificates for authentication, but in fact they don't validate the whole certificate chain—only the public key is used (which makes such authentication incomplete and similar to SSH key authentication).

Here's the brief list of pros and cons of the two protocols:

FTPS

Pros:

• Widely known and used
• The communication can be read and understood by humans
• Provides services for server-to-server file transfer
• SSL/TLS has good authentication mechanisms (X.509 certificate features)
• FTP and SSL/TLS support is built into many Internet communication frameworks

Cons:

• Doesn't have a uniform directory listing format
• Requires a secondary DATA channel, which makes it hard to use behind the firewalls
• Doesn't define a standard for file name character sets (encodings)
• Not all FTP servers support SSL/TLS
• Doesn't have a standard way to get and change file and directory attributes

SFTP

Pros:

• Has good standards background that strictly defines most (if not all) aspects of operations
• Has only one connection (no need for DATA connection)
• The connection is always secured
• The directory listing is uniform and machine-readable
• The protocol includes operations for permission and attribute manipulation, file locking, and more functionality

Cons:

• The communication is binary and can't be logged "as is" for human reading
• SSH keys are harder to manage and validate
• The standards define certain things as optional or recommended, which leads to certain compatibility problems between different software titles from different vendors
• No server-to-server copy and recursive directory removal operations
• No built-in SSH/SFTP support in VCL and .NET frameworks

What to Choose

As usual, the answer depends on what your goals and requirements are. In general, SFTP is technologically superior to FTPS. Of course, it's a good idea to implement support for both protocols, but they are different in concepts, in supported commands, and in many other things.

It's a good idea to use FTPS when you have a server that needs to be accessed from personal devices (smartphones, PDAs, and the like) or from some specific operating systems that have FTP support but don't have SSH/SFTP clients. If you are building a custom security solution, SFTP is probably the better option.

As for the client side, the requirements are defined by the server(s) that you plan to connect to. When connecting to Internet servers, SFTP is more popular because it's supported by Linux and UNIX servers by default.

For private host-to-host transfer, you can use both SFTP and FTPS. For FTPS, you would need to search for a free FTPS client and server software or purchase a license for commercial one. For SFTP support, you can install an OpenSSH package that provides free client and server software.

Developer Tools

If you are a software developer and need to implement file transfer capability in your application, you will be searching for the components to do the job.

In .NET, you have built-in support for FTPS in the .NET Framework (see the FtpWebRequest class). However, functionality of this class is severely limited, especially in the SSL/TLS control aspect. The .NET Framework doesn't include any support for SSH or SFTP.

In VCL, you have a selection of free components and libraries that provide FTP functionality. When you add OpenSSL to them, you can get FTPS for free. If you don't want to deal with OpenSSL DLLs, you can use one of the commercially available libraries for SSL and FTPS support. Again, there are no freeware SFTP components available for .NET.

If you use a tool with which you have to use ActiveX controls, you need to search for commercial FTPS or SFTP controls. No free controls are available. SecureBlackbox library provides both FTPS and SFTP support for .NET, VCL and ActiveX technologies.