SFTP and FTPS both transfer files securely, but they are different protocols. The similar names are easy to mix up—and choosing the wrong one can leave you troubleshooting the wrong port, client, or firewall rule.
The practical distinction is simple: SFTP runs over SSH, while FTPS adds TLS to FTP. They are not interchangeable, so first confirm which protocol the server or integration partner expects.
The differences that matter day to day
| SFTP | FTPS | |
|---|---|---|
| Built on | SSH | FTP secured with TLS |
| Typical control port | TCP 22, or the server’s configured SSH port | TCP 21 for explicit FTPS; conventionally TCP 990 for implicit FTPS |
| Connections | One connection for commands and file data | Separate control and data connections |
| Common authentication | Password, SSH key, or keyboard-interactive | Password; can also use client X.509 certificates |
| Firewall setup | Usually one port | Control port plus data-connection ports |
SFTP is a file-transfer subsystem of SSH. If you already connect to a server with SSH, you may be able to transfer files using the same service and authentication setup. That depends on the server: a working SSH shell does not guarantee that its SFTP subsystem is enabled. For a protocol-level explanation, see what SFTP is and how it differs from a normal SSH session.
FTPS is FTP with TLS protection. It retains FTP’s separate control and data connections, so opening the control port alone may not be enough to make transfers work.
Why FTPS can be trickier through a firewall
FTPS has two choices that are easy to confuse:
- Explicit vs. implicit describes how TLS starts. Explicit FTPS usually connects on port 21, then upgrades the control connection with TLS. Implicit FTPS conventionally starts TLS immediately on port 990.
- Active vs. passive describes how the data connection is established. In active mode, the server opens a connection back to the client. In passive mode, the client connects to a port specified by the server.
These are separate decisions. For passive FTPS, the server generally needs a configured range of data ports, and the firewall must allow that range. Active mode can run into client-side firewall or NAT restrictions because the server needs to connect back to the client.
SFTP avoids this separate data-channel setup: commands and file contents travel through one SSH connection. If you need to understand FTP’s control and data ports in more detail, this guide to FTP ports and passive mode explains the moving parts.
Security is about the configuration, too
Neither protocol is automatically more secure in every deployment. SSH and TLS are both established security protocols; the details of how they are configured and managed matter.
For SFTP, access commonly uses SSH passwords, public keys, or keyboard-interactive authentication. With public-key authentication, the server must be configured to accept the user’s public key. Protect private keys and remove access when it is no longer needed.
FTPS can use server certificates and, where required, client X.509 certificates. That can fit an organization that already operates a certificate authority and needs client-certificate authentication. But certificates bring their own operational tasks, including issuance, expiry, trust, and revocation.
With FTPS, also verify that the data connection is protected—not only the login and control channel. The server and client need to negotiate protected data transfers, and the server should be configured appropriately. Whichever protocol you use, check for outdated protocol versions or weak cryptographic settings and follow the security requirements of your environment.
Which one should you choose?
For a new file-transfer setup with no outside constraints, SFTP is often simpler to operate. It uses one connection, commonly works with existing SSH infrastructure, and avoids configuring a separate FTP data-port range.
FTPS may be the better fit when:
- A customer, supplier, or platform specifically requires FTPS.
- You already operate FTP infrastructure and want to keep it.
- Your organization’s requirements call for X.509 client certificates and you already manage that certificate workflow.
Don’t select a protocol based on a blanket claim that it is faster or more secure. Throughput depends on the workload, network, server, and configuration; test with representative files if performance is important. For security, evaluate the actual configuration and how your team manages credentials and updates.
A quick troubleshooting checklist
If a transfer fails, confirm the protocol before changing firewall rules:
- Check the server’s required protocol. An SFTP client cannot connect to an FTPS server, or vice versa.
- Confirm the connection mode and control port. SFTP normally uses the server’s SSH port; explicit and implicit FTPS conventionally use different control ports.
- For FTPS, check the data connection. Confirm active or passive mode, the server’s passive port range if applicable, and firewall or NAT rules for the data channel.
- Check the service and authentication separately. SSH access alone does not prove SFTP is enabled. For FTPS, confirm the TLS setup and whether client certificates are required.
The useful rule of thumb: SFTP is file transfer over SSH; FTPS is FTP protected with TLS. Start with the protocol your other side supports, then configure the matching client, authentication, and network path.
I originally published a more detailed version of this guide on the SSHFlow blog.
I'm also building SSHFlow — an SSH client where every server gets its own workspace for terminals, SFTP, code, and databases.
Top comments (0)