File Transfer Protocols: Part 2 — FTPS or SFTP

FTPS and SFTP differ by a single letter, and they are often confused. In fact they are two different protocols with different designs. FTPS is regular FTP with TLS encryption added. SFTP is a standalone protocol that operates inside an SSH connection and has nothing to do with FTP.

FTPS: FTP with TLS encryption

FTPS keeps all the FTP logic — two connections, commands, active and passive mode — but wraps them in TLS, the same protocol that protects HTTPS. There are two variants.

Explicit FTPS (explicit, AUTH TLS). Described in RFC 4217. The client connects to the usual port 21 and issues the AUTH TLS command to request switching to a secure channel. The server may allow unencrypted sessions as well, so it is important to require TLS forcibly (in vsftpd — parameters force_local_logins_ssl and force_local_data_ssl).

Implicit FTPS (implicit). TLS starts immediately upon connection, without commands. Separate ports are allocated for it: 990 for the control connection and 989 for data. This is an older variant that never became the standard, but many clients and servers still support it.

Advantages of FTPS:

• uses regular certificates — the same as for a website, for example from Let’s Encrypt;
• compatible with systems that “only understand” FTP and know how to enable TLS.

Its weaknesses are inherited from FTP:

• there are still two connections, and passive mode requires a port range;
• NAT and firewalls cannot see the contents of the encrypted control channel and cannot “peek” which port to open for the data connection, so rules have to be specified rigidly;
• more settings: certificate, mode, port range, enforced encryption.

SFTP: file transfer over SSH

SFTP (SSH File Transfer Protocol) is a subsystem of SSH. The client connects to the same SSH server on port 22, performs standard SSH authentication — by password or, preferably, by key — and within this single connection transfers files, retrieves directory listings, renames and deletes files.

Advantages of SFTP:

• one connection and one port — no issues with passive mode and NAT;
• the server is already present — OpenSSH is installed on almost every Linux server and includes an SFTP server;
• keys instead of passwords — you can completely do away with passwords;
• wide client support — FileZilla, WinSCP, Cyberduck, sftp on the command line, file managers on Linux and macOS.

Isolating SFTP users: chroot

A common task is to give a contractor or counterparty access to a single directory for file exchange, without shell access and without access to the rest of the system. In OpenSSH this is done with a Match block in /etc/ssh/sshd_config:

# /etc/ssh/sshd_config
Subsystem sftp internal-sftp

Match Group sftponly
    ChrootDirectory /srv/sftp/%u
    ForceCommand internal-sftp
    AllowTcpForwarding no
    X11Forwarding no

• ForceCommand internal-sftp starts the built-in SFTP server and prevents running any other commands. According to the documentation it does not require auxiliary files inside the chroot.
• ChrootDirectory locks the user into their directory; %u substitutes the username.
• AllowTcpForwarding no and X11Forwarding no are needed explicitly: the sshd documentation warns that ForceCommand by itself does not forbid port forwarding over the connection.

The main requirement for chroot: according to the sshd documentation, it checks that all components of the path are owned by root and not writable by group or others. Therefore the user’s directory itself is made “read-only”, and a subdirectory is created for uploads:

sudo groupadd sftponly
sudo useradd -m -d /srv/sftp/partner -G sftponly -s /usr/sbin/nologin partner
sudo chown root:root /srv/sftp /srv/sftp/partner
sudo chmod 755 /srv/sftp /srv/sftp/partner
sudo mkdir /srv/sftp/partner/upload
sudo chown partner:partner /srv/sftp/partner/upload
sudo sshd -t && sudo systemctl reload ssh

The command sshd -t checks the configuration before reloading the service: an error in sshd_config on a remote server can lock you out of SSH access.

Comparison

Which to choose

• New file exchange, your own server — SFTP. Easier to configure, one port, keys instead of passwords.
• Counterparty or equipment supports only FTP — FTPS with enforced encryption, a separate account and a narrow port range.
• Need web access for people without clients — neither: better to use a cloud storage solution such as Nextcloud, or WebDAV.

Common mistakes

• FTPS without enforced TLS. The server accepts unencrypted sessions, and some clients connect without encryption without noticing.
• Chroot directory owned by the user. sshd rejects the connection; the log shows a message about incorrect owner or directory permissions.
• SFTP user with a regular shell. Without ForceCommand internal-sftp and nologin the user will be able to log in via SSH and execute commands.
• Passwords instead of keys for permanent transfers. For automated uploads use a separate key with no shell access.