SFTP vs FTPS
Both protocols provide encrypted file transfer, but their architectures differ fundamentally. SFTP is a subsystem of SSH – it uses a single TCP connection on port 22 for all operations. FTPS inherits FTP's dual-channel design: a control channel for commands and a separate data channel for file contents, both wrapped in TLS. The single-connection model of SFTP makes it far easier to firewall (open port 22, done). FTPS requires opening the control port plus a range of passive data ports, and NAT devices must understand FTP to rewrite addresses in the encrypted control channel (which TLS prevents). FTPS exists primarily for organizations with existing FTP infrastructure and clients that do not support SFTP.
SFTP runs over SSH (port 22) using a single encrypted connection for commands and data. FTPS wraps FTP in TLS but still uses separate control (990) and data (989) channels, causing NAT/firewall issues. SFTP is simpler to firewall, deploy, and troubleshoot. FTPS exists mainly for legacy FTP client compatibility.
| Feature | SFTP | FTPS |
|---|---|---|
| Underlying protocol | SSH subsystem (single binary protocol) | FTP commands wrapped in TLS |
| Ports required | Single port (22) | Control (990/21) + passive data range (1024-65535) |
| Firewall friendliness | Excellent – one port, one connection | Poor – dynamic data ports break stateful firewalls |
| NAT traversal | Works through NAT transparently | Requires ALG or explicit passive port range in NAT |
| Authentication | Password, public key, Kerberos, certificate | Username/password, client TLS certificates |
| Server identity | SSH host key fingerprint | X.509 certificate (CA-signed or self-signed) |
| Resume/restart | Supported (seek to offset) | REST command supported |
| Directory listing | Standardized format (SFTP protocol) | Non-standardized (LIST output varies by server) |
| Symbolic links | Supported natively | Not supported in FTP protocol |
| Atomic rename | Supported (rename is atomic) | RNFR/RNTO – not guaranteed atomic |
| Client availability | Every OS ships with sftp/scp | Requires explicit FTP client with TLS support |
When to use SFTP
Use SFTP for all new file transfer deployments: server-to-server automation, user file access, CI/CD artifact transfer. OpenSSH ships with every Linux server – no additional software needed. Key-based auth eliminates password management entirely.
When to use FTPS
Use FTPS only when integrating with legacy systems that only support FTP/FTPS – mainframes, EDI trading partners, and legacy ERP systems. Some compliance frameworks (PCI-DSS for specific card brands) mandate FTPS for historical reasons.
Common Mistakes
- Confusing SFTP with FTPS – they are entirely different protocols. SFTP uses SSH, FTPS uses FTP+TLS. An SFTP client cannot connect to an FTPS server.
- Opening a wide passive port range (1024-65535) for FTPS and forgetting to restrict it – this negates firewall security. Configure a narrow range (e.g., 50000-50100).
- Using password authentication for SFTP automated transfers – use dedicated SSH keys with restricted commands (command= in authorized_keys) and chroot.
- Assuming 'FTP over SSH' means SFTP – some tools tunnel legacy FTP through SSH port forwarding, which is not SFTP but FTP-over-SSH-tunnel (different, fragile).
FAQ
Is SCP the same as SFTP?
No. SCP uses SSH for file copy but does not support directory listings, resume, or remote file operations. SFTP is the full-featured replacement. OpenSSH deprecated SCP's protocol in favor of SFTP internally.
Which is faster?
SFTP is typically faster because it uses a single connection. FTPS data channel setup adds latency per file. For bulk transfers of many small files, SFTP's advantage is significant.