SFTP vs FTPS: ports, firewalls, security and which to use

Short answer: SFTP and FTPS both encrypt file transfers but are unrelated protocols. SFTP runs inside SSH on one port (22) with keys or passwords. FTPS is FTP plus TLS: a control connection on port 21 (explicit) or 990 (implicit) plus passive data ports. Use SFTP on your own server, FTPS when a partner only speaks FTP.

sftp alice@203.0.113.10                        # SFTP: one SSH connection on port 22
curl --ssl-reqd -u alice ftp://203.0.113.10/   # explicit FTPS: port 21, then AUTH TLS
curl -u alice ftps://203.0.113.10/             # implicit FTPS: TLS from the first byte on 990

The SFTP-only configuration below was checked with sshd -t and sshd -T on Debian 12 (OpenSSH 9.2p1). The FTPS details come from RFC 4217 and the vsftpd manual. If you only need the port numbers and a working vsftpd setup, the FTP port guide has them; this page is about choosing between the protocols.

SFTP vs FTPS vs FTP vs SCP at a glance

The names are the main source of confusion. SFTP is the SSH File Transfer Protocol and has nothing in common with FTP beyond moving files. FTPS is FTP as standardised in 1985, with the same two-connection design, wrapped in the same TLS that protects HTTPS. People who say “FTP over SSH” almost always mean SFTP.

How SFTP works

The client opens an ordinary SSH connection, proves who it is, and then asks for the sftp subsystem instead of a shell. Every command, every file and the password travel inside that one encrypted channel. On Debian and Ubuntu, sshd_config already contains Subsystem sftp /usr/lib/openssh/sftp-server, so any server you can reach with ssh also speaks SFTP, with the same accounts and the same keys.

The server proves its identity with its SSH host key. The first time you connect, the client shows a fingerprint and stores it in known_hosts; after that, a changed key stops the connection with Host key verification failed. That check is only as good as your habit of comparing the fingerprint the first time. For the client side and its commands, see the sftp command guide.

How FTPS works: explicit and implicit

Explicit FTPS (sometimes called FTPES) connects to port 21 like plain FTP, then sends AUTH TLS to upgrade the control connection before the login. PBSZ 0 and PROT P then switch the data connections to TLS as well. This is the variant RFC 4217 standardises and the one to pick. Implicit FTPS starts TLS immediately on port 990, with no plain-text phase at all. It is older, was never part of RFC 4217, and survives because some clients and devices still expect it.

Either way, FTPS keeps FTP’s split between a control connection and separate data connections. In passive mode the server announces a port for every listing and every file, and the client connects to it. Behind NAT, routers used to read that announcement on port 21 and fix it up; with TLS they cannot, so the server has to advertise its public address itself (pasv_address in vsftpd) and a fixed range has to be open in the firewall. That is the usual reason an FTPS setup fails where plain FTP seemed to work.

Two more FTPS habits catch people out. The server presents an X.509 certificate, and a self-signed one makes every client ask the user to trust it; a Let’s Encrypt certificate for the server’s hostname avoids that. And vsftpd defaults to require_ssl_reuse=YES, which, per its manual, requires every TLS data connection to reuse the control connection’s TLS session. Some clients do not, and the transfer fails with a 522 reply that mentions session reuse.

Is SFTP or FTPS more secure?

Configured properly, both use modern ciphers and neither is broken. The practical differences are about how easy it is to get the configuration wrong:

• No plain-text fallback in SFTP. An FTPS client set to “use TLS if available” quietly logs in over plain FTP when the server does not offer TLS, and an attacker in the path can make it look that way. Set the client to require TLS, and the server to refuse logins without it.
• Server identity. FTPS borrows the web’s certificate system, so a valid certificate is checked automatically. SFTP relies on the host key fingerprint, which people tend to accept without comparing.
• Keys instead of passwords. SFTP accounts can log in with SSH keys and have passwords switched off entirely. FTPS logins are almost always passwords.
• What the account can do. An SFTP user is an SSH user. Unless you restrict it, the same credentials open a shell and can forward ports. The next section locks that down.

Both are brute-forced around the clock once they face the internet, so put fail2ban in front of either one.

An SFTP-only user with Match and ChrootDirectory

This account can upload into its own directory over SFTP and nothing else: no shell, no port forwarding, keys only, and its authorized_keys file kept outside the jail where the user cannot change it. Everything here is in the sshd_config man page: Match applies the indented options to one group, ChrootDirectory locks the session into a directory, and ForceCommand internal-sftp runs sshd’s built-in SFTP server, which needs no support files inside the jail.

sudo groupadd sftponly
sudo useradd -M -d /srv/sftp/alice -s /usr/sbin/nologin -G sftponly alice

# the jail: every directory on the path must belong to root and be writable only by root
sudo install -d -o root -g root -m 755 /srv/sftp /srv/sftp/alice
sudo install -d -o alice -g alice -m 750 /srv/sftp/alice/upload

# the key lives outside the jail, owned by root (alice.pub: her public key, copied up first)
sudo install -d -o root -g root -m 755 /etc/ssh/authorized_keys
sudo install -o root -g root -m 644 alice.pub /etc/ssh/authorized_keys/alice

Add this block at the very end of /etc/ssh/sshd_config. A Match block runs until the next Match line or the end of the file, so anything placed after it would apply to this group only.

Match Group sftponly
    ChrootDirectory /srv/sftp/%u
    ForceCommand internal-sftp -d /upload
    AuthorizedKeysFile /etc/ssh/authorized_keys/%u
    PasswordAuthentication no
    AllowTcpForwarding no
    X11Forwarding no
    PermitTunnel no

%u stands for the user name, so one block serves every member of the group. -d /upload is the start directory, given as a path inside the jail. Check the syntax, then ask sshd what it would apply to alice before reloading:

sudo sshd -t
sudo sshd -T -C user=alice,host=client.example,addr=198.51.100.7 \
  | grep -E '^(passwordauthentication|forcecommand|chrootdirectory|authorizedkeysfile)'
sudo systemctl reload ssh

passwordauthentication no
forcecommand internal-sftp -d /upload
chrootdirectory /srv/sftp/%u
authorizedkeysfile /etc/ssh/authorized_keys/%u

For any user outside the group, the same command prints chrootdirectory none and forcecommand none, which is how you confirm the block did not leak into the global settings. Keep your current SSH session open and test from a second window: sftp -i ~/.ssh/alice alice@203.0.113.10 should land in /upload, and a plain ssh login as alice is refused with This service allows sftp connections only.

When the SFTP-only login fails

• The connection closes right after the login. Run sudo journalctl -u ssh -n 20. bad ownership or modes for chroot directory means a directory on the path is not owned by root or is group or world writable; fix it with the install -d lines above. The journalctl guide shows how to follow the log live.
• Uploads fail with Permission denied. The top of the jail belongs to root by design. The user writes into upload/, which is why the start directory points there.
• The key is refused. sshd ignores a key file that others can write to. Keep /etc/ssh/authorized_keys at 755 and the file at 644, both owned by root.

What each protocol needs in the firewall

# SFTP and SCP: the SSH port, nothing else
sudo ufw allow 22/tcp

# explicit FTPS: control port plus the passive range set in the FTP server
sudo ufw allow 21/tcp
sudo ufw allow 40000:40100/tcp

# implicit FTPS, only if a client insists on it
sudo ufw allow 990/tcp

The passive range has to match the one configured in the FTP server, and both have to be open on any cloud or hardware firewall in front of the machine as well. If you moved SSH to another port, SFTP moved with it; see changing the SSH port and the ufw guide. A domain proxied through Cloudflare carries neither protocol, so connect to the IP address or to a DNS-only hostname.

Which is faster?

It depends on the files. FTPS sends each file as a raw TLS stream on its own connection, which suits a few large files over a long distance. SFTP splits a file into requests and waits for answers; OpenSSH’s sftp keeps 64 requests of 32 KB in flight by default (per its man page, tunable with -R and -B), which hides most of the round-trip delay. For thousands of small files the picture flips: FTPS opens a new data connection, with a TLS handshake, for every file and every listing, while SFTP keeps reusing the one connection.

For moving a whole directory tree, neither is the best tool. rsync over SSH sends only what changed and resumes cleanly, and the scp command is the quickest way to push a single file. Both use the same SSH port and keys as SFTP.

Clients and servers

On the server side, SFTP comes with OpenSSH, which every Linux server already runs, and with the OpenSSH Server feature on Windows Server (see SSH on Windows). FTPS needs a separate FTP daemon: vsftpd, ProFTPD or Pure-FTPd on Linux, the IIS FTP server on Windows. ProFTPD can serve SFTP too, through its mod_sftp module.

Which one should you use?

• Your own VPS or dedicated server: SFTP. It is already running, needs one port, and works with keys. Lock outside users into an SFTP-only group as above.
• A partner, bank or managed file transfer system that only offers FTPS: explicit FTPS with TLS required on both connections and a fixed passive range.
• A scanner, camera or NAS that only speaks FTP: FTPS if the device supports it, otherwise plain FTP on a private network or through a VPN only.
• Copying files between your own machines: scp or rsync over SSH; SFTP when you want to browse first. Transferring files to a VPS compares the tools.

Every VMHeaven KVM plan comes with full root on Linux, so SFTP works from the first SSH login, and an FTPS daemon is an apt install away if a partner needs it. A Plesk hosting account lists its FTP and SFTP ports in the panel instead.

Frequently asked