I had an exchange with some third party sysadmin yesterday regarding the setup of a file transfer interface between our servers.

I suggested using SFTP because our application has good support for it. My interlocutor absolutely wants FTP+S (FTP+TLS) which we currently don't support and would need to develop.

I argued that I did not see any real benefit in FTP+S over SFTP since both offer solid traffic encryption. SFTP is readily available and can be made even more secure with public key authentification. Last but not least, its single connection mode makes it much nicer to use behind corporate firewalls.

The sysadmin almost called me an idiot, stating that SFTP works on top of SSH which is a protocol designed for administration purpose, and that opening a SSH port for any other use than administration is clearly a bad idea because it opens a broad attack vector against the host system.

I am wondering if this argument is valid. There seem to be various ways to restrict a SSH session to only allow SFTP file transfer. There is the internal-sftp subsystem that comes with openSSH, where you can easily set up a chroot and disable TCP forwarding. I even heard about solutions that presumably allow users to connect via SFTP without requiring an entry in the passwd file... I do not see any clear problem with SFTP that you would not have with FTP+S, but I could be missing something?

So, despite of the restrictions that you can apply to SSH, is FTP+S a better option for file transfers, security wise?

  • 20
    Who's running the server? They get to decide what protocol they run; adapting to a customer's (client's) request is a social problem, forcing a choice on the customer is the same. If they are the server and are running FTPS, your client needs to support that. If you are running the server, it's your security. – CGCampbell Apr 28 '16 at 11:46
  • 11
    Sorry if that was not clear but the whole question is about whether arguments are valid or not. The scenario was provided to give some context, who should have the last word is a different matter. – Stéphane C. Apr 28 '16 at 12:28
  • 2
    There is also HTTPS with WebDAV extensions. That has all the advantages of FTPS (however small they are), but not its disadvantages as it runs over single connection too. – Jan Hudec Apr 28 '16 at 14:01
  • 2
    I would add that you can also do sftp with traditional ftp servers such as proftpd, so you can have a familiar setup (chroots, virtual directories, etc) withouht having to tune up your openssh server. See proftpd.org/docs/contrib/mod_sftp.html – Aseques Apr 29 '16 at 7:46
  • 1
    If the server already runs SSH for administration purposes, SFTP may be preferred in order to limit the attack surface to only one service rather than two. – kasperd Apr 29 '16 at 14:01

From the security they provide in theory FTPS and SFTP are similar. In practice you have the following advantages and disadvantages:

  • With FTPS client applications often fail to validate the certificates properly, which effectively means man in the middle is possible. With SFTP instead users simply skip information about the host key and accept anything, so the result is the same.
  • But users and admins with more knowledge could make use of SSH keys properly and use these also for authentication which then makes SFTP much easier to use compared to using passwords. And if passwords are forbidden at all then this is also more secure because brute force password attacks are no longer possible.
  • FTP uses dynamic ports for data connections and information about these ports is transferred in-band. This makes already plain FTP (without TLS) a nightmare when firewalls, NAT or similar is involved. With FTPS (FTP+TLS) this gets even worse because due to the encryption of the control connection helper applications on the firewall can no longer find out which ports need to be opened. This means that to pass FTPS you would need to open a wide range of ports which is bad for security(*). SFTP is much better because it uses only a single connection for control and data.
  • FTP(S) servers often provide anonymous access and SFTP servers usually don't. Several FTP(S) servers also offer pseudo users, i.e. users taken from same database or similar which are not real users on the system. If you have proper users only anyway this does not matter.
  • SFTP uses the SSH protocol and you have to configure the system properly to only allow SFTP access and not also SSH (terminal) access or even SSH forwarding. With FTP this is easier because FTP can do only file transfer anyway.

(*) Several comments do not really believe that having a wide range of ports open is bad for security. Thus let me explain this in more detail:

  • FTP uses separate TCP connections for data transfer. Which ports are used for these connection are dynamic and information about these gets exchanged inside the control connection. A firewall which does not know which ports are in use currently can only allow a wide port range which maybe will be used sometimes FTP.
  • These ports need to allow access from outside to inside because in FTP passive mode the client connects to some dynamic port on the server (i.e. relevant for server side firewall) and for FTP active mode the server connects to some dynamic port on the client (relevant for client side firewall).
  • Having a wide range of ports open for unrestricted access from outside to inside is not what somebody usually considers a restrictive firewall which protects the inside. This is more similar to having a big hole in the door where a burglar might come into the house.
  • To work around this problem most firewalls employ "helpers" for FTP which look into the FTP control connection to figure out which ports need to be opened for the next data connection. One example is ip_conntrack_ftp for iptables. Unfortunately with FTPS the control connection is (usually) encrypted so these helpers are blind and cannot dynamically open the required ports. This means either FTP does not work or a wide range of ports need to be open all the time.
  • 14
    Regarding the last bullet point: the SITE command (esp. SITE EXEC) has a pretty bad history in terms of security/exploits. The "can only do file transfers" is only true of a sane and correctly configured FTP server. – Mat Apr 28 '16 at 10:06
  • 14
    FTP is a stupid protocol and needs to die. – André Borie Apr 28 '16 at 12:38
  • 6
    "open a wide range of ports (which is insecure!)" Without any reasons given as to why that would be insecure, I think it's a bit of an odd statement. I generally disagree (if your security depends upon ports being closed, something is probably wrong), but I thought I'd comment and ask before just editing it... (Overall, good answer though -- upvoted.) – Luc Apr 28 '16 at 12:52
  • 6
    @Luc: I thought it was obvious why opening a wide range of ports in a firewall is a bad idea. But I reworded this part so it is hopefully more clear. And of course your security should not depend on ports being closed but such restrictions are part of security in depth. Having unrestricted access from outside to inside on a wide range of ports is just a bad idea even if the systems inside are considered (mostly) secure. – Steffen Ullrich Apr 28 '16 at 13:22
  • 4
    @SteffenUllrich your edit didn't actually explain how the system is made less secure by having ports accessible. Having the FTP server listening on multiple ports is no less secure than having it listening on just one. I know your advise is popular, but as far as I know it's popularity is just cargo-culting. – André Paramés Apr 28 '16 at 15:14

The sysadmin raises a valid point. (but his interpersonal skills might need work)

SSH is a complex protocol, and openssh implements a lot of functionality. All this functionality offers attack vectors, and it is very hard to be sure that none of these vectors are exploitable.

Even if openssh is without bugs (which it isn't), knowing about all the right possibilities to close off unwanted functionality, and understanding how these options might interact takes significant effort in itself. And these interactions might change from version to version.

As an example, consider the following sshd_config snippet, which has the intention of limiting certain users to SFTP-only (we even thought of locking them to their home directories):

Match Group sftponly
    ChrootDirectory %h
    ForceCommand internal-sftp

And sure enough:

% ssh somehost
This service allows sftp connections only.
Connection to somehost closed.

But wait...

ssh -N -L 9000:localhost:80 somehost

Whoops, I now have forwarded port 80 on somehost to port 9000 on my host. That means we can connect to port 80 on somehost as if we are coming from localhost. Probably not a big deal for port 80, but what about services that only listen on localhost, such as administrative services or databases?

And that's just TCP forwarding. At the very least, SSH also allows X11 forwarding and SSH-agent forwarding, and I don't even know the implications of those two.

We do use ssh/sftp a lot, because for our situation the advantages outweigh these risks. But it is a valid concern that should not be taken too lightly. We ended up with this for use cases where just sftp is enough:

Match Group sftponly
    ChrootDirectory %h
    X11Forwarding no
    AllowTcpForwarding no
    AllowAgentForwarding no
    ForceCommand internal-sftp

We hope this is adequate to ensure just sftp access, but we can't be completely sure. (suggestions welcome ;)

  • Still, in order to be able to do any damage, attackers still need to get past authentication which can be extremely difficult. Then I understand that you need to make sure that all doors are closed and that perhaps this would make SFTP more risky if you only have limited trust in your users – Stéphane C. Apr 28 '16 at 11:13
  • 2
    @StéphaneC. True. But you mentioned he's a third party sysadmin. So why would he trust you and give you potentially more access than you need? It's not just about malicious intent on your side; what if your machines get compromised? ;) – marcelm Apr 28 '16 at 11:24
  • Correct, but as stated above there can be complications and potential FW issues involved by the multi-socket architecture of this protocol. I guess it's a trade-off. Does that outweigh the potential (or almost theorical?) security risk of SFTP? Difficult for me to tell... – Stéphane C. Apr 28 '16 at 12:00
  • 2
    It's a trade-off indeed. Honestly, if I had to give third parties with whom I'm not intimately familiar file-access to one of our servers, I probably wouldn't go for sftp. But for us it's mostly internal and occasionally with trusted third parties, so for us the advantages of ssh/sftp win. – marcelm Apr 28 '16 at 12:17
  • 11
    Remember that, while OpenSSH is complex and has a large attack surface, it also makes extensive use of privilege separation, such as seccomp, a child with reduced privileges which communicates only through a pipe, rlimits, and more. I don't believe any ftps client has similar functionality. So it's difficult to say that OpenSSH has more attack surface when it's also locked down far more extensively. – forest Apr 29 '16 at 7:57

Both protocols have advantages and disadvantages, as explained very well in this comparison article.

This said, since the question is specifically regarding security, there are a few considerations that should be taken into account when choosing which protocol is best in certain specific conditions.

FTPS and FTPES use SSL or TLS to encrypt the control/data connections. The main advantage of these secure channels is that they use X.509 certificates, which contain much more information that a simple key pair (host name, email address, organization name, the ISSUER (CA), ...) and are therefore a lot easier to validate. But:

  • SSL 1.0, SSL 2.0: deprecated long time ago (insecure)
  • SSL 3.0: recently deprecated because of POODLE
  • TLS 1.0: no longer acceptable for PCI compliance
  • TLS 1.1: lacks some of the extensions of TLS 1.2, and has limited client support, no reason to use it
  • TLS 1.2: current standard, so far considered secure/safe

And the above only covers the channel(s) encryption protocol, then there are safety considerations regarding the FTP protocol itself. The SITE command, for example, has been used over and over to perpetrate attacks, and the inherent design of the protocol itself requires to open and NAT multiple ports on your firewall (which can become a nightmare to manage). Furthermore, most firewalls are not able to properly NAT FTP-data connections unless the client requests and the server allows CCC (Clear Control Channel) which defeats part of the security by running the control connection unencrypted.

On the other hand we have SFTP, which is a subsystem of SSH. The main challenge here is that SSH keys are "just keys", they are not issued by a CA and no issuer statement or key-chain is included in them, therefore SSH server keys have to be expressively trusted by the client.

Someone may argue that configuring an SSH server to only allow SFTP (no shell, no commands, no forwarding tunnels, no X11) may be difficult. That actually depends: if you're running Linux and OpenSSH that might be true, but there's a plethora of SSH/SFTP servers out there that make this kind of configuration a breeze, so I wouldn't necessarily list this as a potential flaw, unless - as I said - Linux/OpenSSH are used.

A couple remarkable side advantages of SFTP, though, include:

  • ECDSA key exchange: a 521-bit ECDS(X) key is equivalent to a 15,360-bit RSA key in terms of security, and requires 9 times less CPU cycles for signature calculation
  • Inherent forward secrecy: the SSH protocol can renegotiate the actual channel encryption key in-session, and provides inherent forward secrecy, as opposed to any SSL/TLS-enabled server that require additional configuration work to accomplish this

So, ultimately the choice is really up to you guys, but the argument that the sysadmin was making is blatantly invalid, and if there is an existing SFTP server that is well configured (as explained) then there is no reason (especially no security-related reason) to switch to FTPS (or FTPES).

  • Can you recommend a SFTP server that makes it easy to set up file transfer only mode? I may consider running something like that on a different port for other projects. – Stéphane C. Apr 28 '16 at 15:11
  • Check out Syncplify.me Server (disclosure: it's the company I work for). I don't think I can put links in comments but I'm sure you can Google it easily. ;) – FjodrSo Apr 28 '16 at 15:13
  • 4
    @StéphaneC. ProFTPD's mod_sftp module also implements SFTP (and SCP), but no shell access. – Castaglia Apr 28 '16 at 16:14
  • @FjodrSo Doesn't ChangeCipherSpec renegotiate session keys in TLS if cipher suites which support this are in use? – reirab Apr 28 '16 at 20:46
  • 3
    SSL/TLS has supported FS with DHE since 1999, and supports ECDH(E) and ECDSA since 2006 -- although the numerous implementors in the SSL/TLS space weren't as active in pushing ECC as the one dominant SSH implementor OpenSSH; for example OpenSSL didn't make ECC in SSL/TLS easy until 2010. @reirab Renegotiation in SSL/TLS does the full handshake sequence, starting with ClientHello (containing Renegotiation Indication if 5746 is used as it nearly always is) or ServerHelloRequest; CCS is only the next-to-last step. SSH can rekey without reauth, although I'm not sure anyone wants to. – dave_thompson_085 Apr 29 '16 at 4:16

Many people bring up valid points about the differences between the two protocols. But I think for your purposes, the question is really "Is SFTP Secure enough?" rather than "which one is more secure"?. As you've said, you have other concerns than simply security.

This turns out to be a difficult problem to solve. SSH has been used extensively and studied extensively. There's no known protocol design flaws. However, security vulnerabilities often have nothing to do with the protocol, and everything to do with the implementation. After all, SMTP itself isn't "insecure", and is relatively simple in design, but 16 years ago the commmon SendMail application was one of the poster children of badly implemented software security, and had hole after hole in it.

The point being, even if the protocol is well designed and simple, the implementation can be a rats nest of complexity, add on features, and security nightmares.

So I think this is more about choosing a good IMPLEMENTATION rather than a good protocol. Either protocol is fine, and either implementation can be poorly implemented.

I'm not entirely familiar with FTPS, so I don't know if there's any well respected implementations of it. For SSH however, OpenSSH is generally regarded as high quality, and was designed with security in mind from the ground up (privledge separation, etc).


Like you, I thought both were almost the same as I went through the web looking for their differences.

However, in real life, it is another story. Below was my experience:

  1. For my NAS, I turned on the FTPS functionality for 3 months. Firewall setup was ok. I just had to open up the FTP port and a few more ports used by FTPS transfer. So far so good, no big deal.

  2. After 3 months, I figure, meh, may be I turn on SFTP protocol as well since it is more common and probably easier to manage. Then something interesting happened. 10 MINUTES after I open up the SFTP port, my NAS was under some bruise force attacks. The NAS automatically blocked the attacking IP after 10 failed password attempts and notify me by e-mail. Imagine if the attacker had control of thousands of computers all having different IPs, my NAS would not be able to stop them all. Also, if the staffs of our company decides to set up really easy password, then the person who uses the bruise force attack may eventually get into our system.

Now that I disabled the SFTP, the attacking stopped and I am happy that no one is trying to get into our file server any more.

  • Any publicly reachable service may face attacks, I am running a few web servers and my auth.log is filled with "root:admin123" style login attempts, generally within minutes after renting them. As for guessing a strong password with brute force, I wish them good luck. I don't think you can blame the protocol for it, maybe use an alternate port and allow only public key auth. – Stéphane C. Mar 25 '17 at 6:26
  • All this anecdote shows is that attackers are constantly hammering your port 22 hoping to catch you with an insecure SSH password. This is not uncommon on the open web and doesn't mean that SSH itself is insecure. Merely changing from port 22 will all but stop these log entries even though security won't be significantly affected. – thomasrutter Sep 26 '17 at 7:25
  • The protocol is common and been around for so long there are more brute force attempts against it, so what? That does not change my opinion that SFTP is among the most secure file transfer methods possible. – pilavdzice Jan 2 '18 at 20:56

No, SSH and SSL usually use the same cipher strenth. e.g: RSA and AES, but SSH can use DSA. But ssh uses port 22. but FTPs uses port 21 and 22 for FTP and FTP Data. tho it is in my opinion better configurable, you have to open 2 ports, which is not only impractical considering firewalls but also a potential security risk, because you have to open 2 ports.

  • FTP[S] uses separate data connection but not port 22. SSL/TLS can use DSA, but it is rare on the public net because public CAs (Symantec GoDaddy etc) mostly don't issue DSA certs; on intranets or closed communities it works fine (and was the only way to get PFS on WinXP). OTOH recent OpenSSH (since 7.0 in 2015) disable ssh-dss by default apparently because SSH is limited to DSA with SHA1; see crypto.stackexchange.com/questions/15051/… – dave_thompson_085 Nov 6 '17 at 14:44

The answer is kinda blunt either which way you go in your rhetoric. Server side means are controlled by the person giving the file and theoretically safer if one knows all security features.

A user side method would be the same but for the user. In these days we do not question the relationship of the two. Each must insure themselves of their abilities to protect themselves sufficiently. Users therefore turn to an option of firewalls.

Any option you choose for the user can easily be overruled by such means. Therefore we do not worry about the user (recipient). This rhetoric is obsolete now on this matter.

Your concern should be on your own securities. This would mean server side. You want control of information you release. How much concern after it is released is no longer prudent. It is simply not your responsibility beyond that point. Only what affects you as a consequence. If you have no data yet on this you have no consequence.

A truly controllable solution would be to use a FTP source with encryption all by your own design. Do not rely on any third parties. But this too is obsolete as it is hard to build your own libraries from start to finish.

Based on the terminologies you supplied inadequately you want a simple ssh ftp. For that all you can do is propose firewall rules and iptables configurations (if in Linux). You seem to be stuck with WYSIWYG either way you go.

  • 3
    Even if building a complete support library was easy, I would not recommend running your own protocol or FTP implementation instead of well-established solutions. Considerable time and experience is invested in security in mainstream SSH/FTPS servers by their maintainers, to a level that would be difficult for you to match. Especially if it is not your main business value. – Stéphane C. Apr 29 '16 at 11:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.