SFTP Is Not FTP
The name is misleading. SFTP shares nothing with FTP beyond the letters. FTP (File Transfer Protocol) was defined in 1971 and works by opening a control channel on port 21 and a separate data channel on a dynamically negotiated port. Everything — credentials, commands, file contents — travels in plaintext. Any observer on the network can read your username, password, and files in full.
SFTP was designed entirely independently as a subsystem of SSH-2. It has its own binary packet format, its own operation codes, and its own session negotiation — all running inside an already-established SSH encrypted channel. The "FTP" in the name was chosen to describe its purpose (secure file transfer), not its heritage. Treat them as unrelated protocols that happen to share an acronym.
How SFTP Works
SFTP runs as a named subsystem of the SSH-2 protocol. When your SFTP client connects, it first establishes a normal SSH session on port 22, authenticates with the server, then sends a channel request asking the server to start the SFTP subsystem. The server launches an SFTP server process (typically /usr/lib/openssh/sftp-server) and pipes its stdin/stdout through the SSH channel.
From that point, client and server exchange binary SFTP packets inside the encrypted SSH stream. Each packet contains a request type (open a file, read bytes, write bytes, list a directory, rename a file, etc.) and a request ID. The server responds to each request independently. Multiple requests can be in flight simultaneously, giving SFTP reasonable throughput without waiting for each round trip to complete.
SFTP Operations: A Full Filesystem Abstraction
SFTP exposes a complete remote filesystem interface — not just upload and download. The protocol supports reading and writing file data at arbitrary offsets, appending to existing files, listing directory contents with full metadata, creating and removing directories, renaming and moving files, deleting files, reading and setting file permissions and timestamps, and creating and resolving symbolic links.
This makes SFTP much more capable than simple copy tools. A backup application can check file modification times before deciding whether to transfer a file. A deployment tool can rename a temporary file into place atomically. A file manager can browse a remote server interactively just as it would a local filesystem. These operations are what distinguish SFTP from SCP, which can only copy a file from point A to point B.
Authentication: Everything SSH Supports
Because SFTP runs inside SSH, it inherits all SSH authentication mechanisms without any additional configuration. Password authentication works out of the box. Public-key authentication — where the client proves possession of a private key without transmitting it — is the recommended method for production use and automated scripts. SSH certificate authentication, where an SSH Certificate Authority signs user keys, is also fully supported and makes key management tractable at scale.
For automated transfers, the typical setup is an SSH key pair with an empty passphrase (so no human interaction is needed at transfer time), with the private key accessible only to the transfer process and the public key installed in the remote account's ~/.ssh/authorized_keys. This provides strong authentication with no password stored in a config file.
Firewall Simplicity
Traditional FTP is a firewall administrator's nightmare. Active mode FTP requires the server to initiate an inbound connection to the client on a dynamically negotiated port — essentially impossible through NAT without special FTP ALG helpers. Passive mode FTP avoids this, but still requires opening a range of high-numbered ports (typically 1024–65535 or a configured subset) for data connections, in addition to port 21 for the control channel.
SFTP uses only port 22. One rule in each direction. No dynamic port negotiation, no mode switching, no ALG requirements. This alone is often the deciding factor when choosing SFTP over FTP or FTPS in enterprise environments where network teams tightly control firewall rules.
SFTP Clients
The command-line sftp client ships with OpenSSH and is available on Linux, macOS, and Windows (via OpenSSH for Windows or WSL). An interactive session works like a minimal shell: ls lists the remote directory, cd changes directories, get remotefile downloads a file, put localfile uploads one, mkdir creates a remote directory. Prefix a command with l (like lcd or lls) to operate on the local filesystem instead.
Graphical clients include FileZilla (cross-platform, free), WinSCP (Windows, free, also supports SCP and FTP), and Cyberduck (macOS and Windows, free with donation prompt). All three support SFTP with both password and public-key authentication. For scripting and application integration, Python's paramiko library provides a full SFTP client API, and lftp supports SFTP with batch scripting and resume capabilities.
SFTP Batch Mode and Scripting
The command-line sftp client supports batch mode for unattended operations. Create a file containing SFTP commands (one per line), then run sftp -b batchfile user@host. The client executes each command in sequence and exits. Combined with SSH key authentication, this enables fully automated file transfers without any interactive prompts. For more sophisticated automation — conditional transfers, parallel uploads, retry logic — Python's paramiko or the lftp tool are better choices, as they expose programmatic control over the transfer process.
SFTP Server Configuration
On OpenSSH servers, SFTP is enabled by a single line in /etc/ssh/sshd_config: Subsystem sftp /usr/lib/openssh/sftp-server. This is present by default in most Linux distributions. For restricted SFTP access — where users should be able to transfer files but not log in to a shell — OpenSSH supports chroot jails. Set ChrootDirectory /home/%u and ForceCommand internal-sftp in a Match User block to confine a user to their home directory with no shell access. This is the standard approach for providing file upload access to external partners without giving them a shell account.
SFTP vs SCP vs rsync
| Feature | SFTP | SCP | rsync over SSH |
|---|---|---|---|
| Protocol base | SSH-2 subsystem | SSH (spawns scp process) | SSH (spawns rsync process) |
| Port | 22 | 22 | 22 |
| Resumable transfers | Protocol supports it; client-dependent | No | Yes (delta algorithm) |
| Directory sync | No (copy only) | Recursive copy only | Yes (syncs deltas) |
| Encryption | Full SSH encryption | Full SSH encryption | Full SSH encryption |
| Scripting ease | Good (batch mode, paramiko) | Simple (single command) | Excellent (many options) |
| Interactive mode | Yes (full filesystem browsing) | No | No |
Frequently Asked Questions
Is SFTP the same as FTP?
No. Despite sharing "FTP" in its name, SFTP and FTP are completely different protocols with no shared code or architecture. FTP was designed in 1971 and transmits data in plaintext over two separate TCP channels. SFTP is a binary subsystem of SSH-2, travels over a single encrypted connection on port 22, and was designed independently in the late 1990s. The name similarity is a historical coincidence — SFTP was coined to describe Secure File Transfer, not an extension of FTP.
What port does SFTP use?
SFTP uses TCP port 22 — the same port as SSH. Because SFTP runs as a subsystem of the SSH protocol, no additional ports are required. This is one of SFTP's major advantages over traditional FTP, which requires port 21 for control and a separate range of ports for data connections, complicating firewall rules significantly.
Is SFTP encrypted?
Yes. SFTP inherits the full encryption of SSH. All authentication data, file contents, directory listings, and commands travel inside the SSH encrypted channel. The encryption algorithm is negotiated during the SSH handshake and typically uses AES-256-GCM or ChaCha20-Poly1305. An observer on the network cannot see what files are being transferred or their contents.
How do I connect to an SFTP server?
From the command line, run sftp user@hostname. This opens an interactive session where you can use commands like ls, cd, get filename, put filename, mkdir, and rm. For graphical clients, FileZilla, WinSCP, and Cyberduck all support SFTP — enter the hostname, your username, and either your password or point the client at your private key file. For scripted transfers, tools like lftp and Python's paramiko library provide SFTP batch capabilities.
Can SFTP resume interrupted transfers?
SFTP supports file-level resume through its append and read-from-offset operations — the protocol itself has the capability. Whether a specific client exposes this as a resume feature depends on the client implementation. FileZilla and WinSCP both support resuming interrupted SFTP transfers. Command-line sftp does not natively resume, but rsync over SSH is a better choice when reliable resumable transfers are the primary requirement.
What is the difference between SFTP and SCP?
Both SFTP and SCP transfer files over SSH, but they differ significantly in capability. SCP is a simple one-direction file copy tool — it streams a file from source to destination and exits. SFTP is a full filesystem protocol that supports interactive browsing, directory operations, file renaming, deletion, permission changes, and batch scripting. OpenSSH 9.0 (2022) deprecated the old SCP protocol and switched the scp command to use SFTP internally. For anything beyond a quick one-off file copy, SFTP is the better choice.