2026
FTP and SFTP: File Transfer Protocols
FTP has been moving files between machines since 1971 and it sends everything in plaintext. SFTP fixed that by being a completely different protocol. Here is what each one actually does and why the distinction matters.
File transfer is one of those problems that feels solved until you look at the specifics. Most people who have touched a Linux server have used FTP at some point. It shows up in shared hosting dashboards, deployment pipelines, legacy data workflows that have been running untouched for years. The protocol is old enough that it predates the internet as most people recognise it today.
The problem with FTP is not that it is old. The problem is what being that old means in practice: it was designed when the machines talking to each other were trusted. Every credential, every command, every byte of file content travels over the network in plaintext. On any network where you cannot account for every device between you and the server, that is a genuine risk.
SFTP solved the problem. FTPS also solved the problem, in a different way. Both exist today. Both are commonly confused with each other. One of them is not actually related to FTP at all despite the name.
What FTP actually is
FTP is an application-layer protocol for transferring files between a client and a server. It was first defined in 1971 and standardised in its current form in RFC 959. The core exchange is simple: the client connects, authenticates, issues commands and the server carries them out.
What makes FTP unusual compared to most other protocols is that it uses two separate TCP connections. The control connection stays open for the life of the session on port 21. It carries all the commands. When file data actually needs to move, a second connection is established just for that transfer. Once the transfer is done, the data connection closes. The next transfer opens a new one.
Typical FTP session on the control channel
220 FTP server ready
USER deploy
331 Password required
PASS hunter2
230 User logged in
PASV
227 Entering Passive Mode (192,168,1,10,196,98)
RETR report.csv
150 Opening data connection
... file contents travel on the data connection ...
226 Transfer complete
That exchange is visible to anyone watching the wire. The username, the password, the filename, the file content: all of it.
FTP control commands
The control channel carries human-readable commands. They read more like a conversation than a protocol. Recognising them makes reading an FTP log straightforward even if you have never opened one before.
Send the username to the server. The server receives this as plaintext before the session is authenticated.
Send the password. Also plaintext. This is the core reason plain FTP is considered unsafe on any untrusted network.
Retrieve a file from the server. File contents travel over a separate data connection, not the control channel.
Upload a file to the server. The client sends file contents over the data connection.
List the contents of the current directory. Output comes back on the data connection.
Change the current working directory on the server.
Delete a named file on the server.
End the session. The server closes the control connection.
Active mode and passive mode
The two-connection model creates a specific problem. When the client sits behind a NAT router, it has a private address the server cannot reach. In active mode the server tries to open the data connection back to the client. The router has no mapping for the incoming connection so it drops the packet. The transfer hangs. Passive mode was introduced to address this.
Active mode
Breaks behind NATThe client opens the control connection to port 21 on the server. When a transfer is needed, the client tells the server which port it is listening on. The server then initiates a connection back to the client from port 20. This worked fine on early networks. It fails badly behind NAT because the server cannot reach an address that is not publicly routable.
Passive mode
Works through NATThe client opens the control connection as before. When a transfer is needed, the client asks the server to open a port. The server picks a high-numbered port, tells the client which one to use, then waits. The client connects to that port. Both connections now originate from the client side, which NAT handles without difficulty. This is the standard for modern FTP clients.
Most modern FTP clients default to passive mode. If you see FTP transfers hanging after the control connection succeeds, the server's passive port range is the first place to check. Passive mode requires a range of high ports to be accessible from the outside, which needs to be explicitly opened in whatever firewall sits in front of the server.
The problem with plain FTP
FTP has no concept of encryption. The control connection carries your username and password as plaintext. The data connection carries your files as plaintext. Every command, every response, every byte of file content is readable by anyone who can observe the traffic between client and server.
On a tightly controlled internal network this might be an acceptable trade-off. In most real environments it is not. A shared hosting server, a cloud instance, a VPS: all of these have traffic that traverses networks you do not control. Capturing FTP credentials on a shared network requires no special skill. Wireshark reads them with no configuration at all.
Worth noting
There is no configuration option that makes plain FTP safe on an untrusted network. The protocol simply does not support encryption. If you need encryption you need a different protocol. SFTP handles this cleanly. FTPS layers TLS on top of FTP if you need to stay compatible with FTP-specific tooling.
SFTP: a different protocol entirely
SFTP stands for SSH File Transfer Protocol. The name causes genuine confusion. It is not FTP with SSH layered on top. It is not FTP at all. It is a completely separate protocol designed from scratch that happens to cover the same use case as FTP: moving files between machines.
SFTP runs as a subsystem of SSH on port 22. If you already have SSH access to a machine, you almost certainly have SFTP access too. The same key-based authentication you use for terminal sessions works for SFTP transfers. There is no second connection to manage. There is no passive mode to configure. Everything travels over the single encrypted SSH session.
The protocol itself is binary rather than text-based. You will not read SFTP traffic in a packet capture the way you can with FTP. The client and server exchange structured binary packets. SSH handles the encryption before any SFTP data touches the wire.
What SFTP inherits from SSH
Working with SFTP in the terminal
The sftp command ships with OpenSSH, which means it is available on essentially any Linux system without installing anything extra. The interactive session it opens feels similar to a shell, though the available commands cover file operations rather than arbitrary execution.
sftp user@hostOpen an interactive SFTP session. Prompts for a password unless key-based auth is configured.
get remote_fileDownload a file from the remote host to your current local directory.
put local_fileUpload a file from your local machine to the current remote directory.
lsList the contents of the remote directory you are currently in.
llsList the contents of your local directory. The l prefix targets local commands.
cd remote_dirChange directory on the remote host.
lcd local_dirChange directory on your local machine without leaving the session.
rm remote_fileDelete a file on the remote host.
byeClose the session cleanly.
For scripted transfers, scp is often simpler for single files. For anything that involves directory listings, selective downloads, resumable transfers, or working with remote paths interactively, the SFTP session handles it better. Tools like FileZilla support SFTP as a first-class option alongside FTP for those who prefer a graphical interface.
FTPS: FTP over TLS
FTPS is the other option when you need encryption but must stay compatible with FTP. Unlike SFTP, FTPS is actually FTP. It adds TLS on top of the existing protocol rather than replacing it. The same commands, the same two-connection model, the same passive mode complexity: all of that is still present. TLS handles the encryption layer.
FTPS comes in two modes. Explicit FTPS starts with a plain FTP connection on port 21. The client issues an AUTH TLS command to upgrade the connection before any credentials are sent. Implicit FTPS expects TLS immediately when the connection opens on port 990. Explicit mode is more widely supported in modern systems. Implicit mode is older.
Explicit FTPS negotiation
220 FTP server ready
AUTH TLS
234 Proceed with TLS negotiation
... TLS handshake happens here ...
USER deploy
331 Password required
PASS ••••••••
... credentials now travel over an encrypted connection ...
230 User logged in
The distinction between FTPS and SFTP matters most when you are configuring server software. An SFTP client will not connect to an FTPS server. An FTP client with TLS support will not speak SFTP. Knowing which protocol the server is running saves considerable confusion when a connection refuses to work despite everything looking correct.
FTP vs SFTP vs FTPS
Three protocols with overlapping names, different origins and different trade-offs. The comparison is worth seeing in one place.
Ports worth knowing
Port numbers come up constantly when configuring firewalls, security groups and server software. Getting them wrong is a common source of connection failures that look mysterious until you check what is actually expected on each end.
21FTP controlAll FTP commands travel here. Also used for the AUTH TLS upgrade in explicit FTPS.20FTP data (active)The server initiates active-mode data connections from this port.22SFTPSFTP is a subsystem of SSH. It uses the same port as all other SSH sessions.990FTPS implicitImplicit FTPS expects TLS immediately on connection, before any FTP commands are exchanged.FTP in passive mode also needs a range of high-numbered ports open on the server side. The exact range is set in the server configuration. ProFTPD, vsftpd and similar servers let you define this explicitly. Forgetting to open that range in a firewall is one of the most common reasons passive mode fails even after the connection on port 21 succeeds without issue.
Which one to use
If you are setting up file transfer today, SFTP is the straightforward answer. It is encrypted, it uses a single connection, it integrates with existing SSH key infrastructure. The client tooling is mature on every platform. If you already have SSH access to a machine, you have SFTP access too without touching any additional configuration.
FTPS makes sense when you are integrating with a system that expects FTP semantics but requires encryption. Some legacy enterprise software, certain EDI workflows, some compliance environments specify FTPS explicitly. In those cases there may not be a meaningful choice to make.
Plain FTP still runs in more places than it should. On an internal network with no external exposure it may be low risk in practice. On anything that touches the internet, replacing it is worth the effort. The credential exposure is real. The fix is not complicated.
Understanding what the protocol is actually doing when you issue a transfer command changes how you think about what is moving across the wire. Most of the time that awareness lives in the background. When something goes wrong, whether a transfer hangs, a firewall blocks a connection, a credential is suspected compromised, that awareness is what points you to the right place to look.