SFTP vs SCP vs FTPS Explained: Secure File Transfer for Network+

Secure file transfer is a reliable source of exam questions because the names are so similar and the ports are so specific. The one that catches people is that SFTP and FTPS are completely different protocols despite the near-identical names.

The protocols and their ports

Protocol	Port	Based on	Encrypted
FTP	TCP 20 (data), 21 (control)	—	No
SFTP	TCP 22	SSH	Yes
SCP	TCP 22	SSH	Yes
FTPS	TCP 989/990, or 21 with AUTH TLS	FTP + TLS	Yes
TFTP	UDP 69	—	No

Memorise that SFTP and SCP both use port 22, because both are carried over SSH. That single fact resolves a lot of questions: if a firewall permits SSH, it permits both.

SFTP versus FTPS

The distinction the exam most wants.

SFTP — SSH File Transfer Protocol. Not FTP at all. It is a distinct protocol running inside an SSH session, using a single connection on port 22.

FTPS — FTP Secure. This is FTP, with TLS wrapped around it. It keeps FTP's two-connection design, one for control and one for data.

The practical consequence is firewall behaviour, and it is worth knowing because it decides which one an organisation chooses.

FTPS inherits FTP's separate data connection, which is negotiated dynamically. In active mode the server connects back to the client, which NAT and client firewalls block. Passive mode helps but requires a range of ports open on the server. And because the control channel is encrypted, a firewall cannot read the negotiation to open the right port automatically — so FTPS through NAT is genuinely awkward.

SFTP uses one connection on one port. It traverses NAT and firewalls without special handling. That is why SFTP is usually the recommended answer.

SFTP versus SCP

Both run over SSH on port 22, and the difference is capability.

SCP copies files. That is all it does — one transfer, no session. It is simple, and historically faster for a single large file because of lower protocol overhead.

SFTP is an interactive file management protocol. It can list directories, rename, delete, create directories, change permissions and resume interrupted transfers.

The decisive point for modern practice: SCP's underlying protocol has known weaknesses, notably that a malicious server can write files outside the intended directory. OpenSSH has deprecated the old SCP protocol and now routes the scp command over SFTP by default. So the command survives while the protocol beneath it has been replaced — and SFTP is the correct answer when asked which to use.

TFTP

Trivial File Transfer Protocol, UDP port 69. No authentication, no encryption, no directory listing. It exists because it is small enough to fit in firmware.

Its legitimate uses are on trusted local networks: PXE network booting, and pushing or pulling configuration and firmware images on network devices. It should never cross an untrusted network, and an exposed TFTP server is a genuine risk because anyone can read from it.

Why plain FTP persists, and what to do about it

FTP sends credentials and data in cleartext. Anyone positioned on the path can capture both, which makes it unacceptable over any untrusted network.

It survives because of legacy integrations and scripts. Migration options are SFTP where you control both ends, FTPS where the far end requires FTP semantics, or a managed file transfer platform where auditing and compliance matter.

Authentication

Since SFTP and SCP ride on SSH, they inherit SSH authentication — which means key-based authentication is available and should be preferred over passwords for automated transfers. Keys avoid embedding a password in a script, and they can be restricted so a key may only run a file transfer and not obtain a shell.

FTPS uses TLS certificates for server identity and typically a username and password for the user, with optional client certificates.

Troubleshooting

SFTP failing where SSH works usually means the SFTP subsystem is disabled on the server. FTPS transfers that connect and then hang on a directory listing are a passive-mode port range problem. TFTP failures are frequently a firewall blocking UDP 69 or the server's directory permissions. And a transfer that works from inside the network but not outside is almost always NAT interacting with FTP's data connection.

What to remember

SFTP and SCP both run over SSH on port 22; FTPS is FTP wrapped in TLS on 989/990 or 21 with AUTH TLS; plain FTP is 20 and 21 and unencrypted; TFTP is UDP 69 with no security at all. SFTP is a different protocol from FTP, not a secured version of it. SFTP is preferred over SCP and traverses firewalls far more easily than FTPS.

Related reading: Port numbers to know · Remote access tools · SNMP