SFTP isn’t actually FTP over SSL/TLS; it’s a completely separate protocol that just happens to use SSH for its transport layer.
Let’s see SFTP in action. Imagine you have a server at sftp.example.com running an SSH server on port 22. You want to upload a file named report.csv to the /uploads/daily directory on that server.
First, you’ll need an SFTP client. sftp is a command-line client available on most Linux and macOS systems.
$ sftp user@sftp.example.com
This command initiates a connection to sftp.example.com as user. You’ll be prompted for the user’s password or, if you’ve set up SSH keys, it will use those.
Once connected, you’ll see an sftp> prompt.
To upload report.csv from your local machine to the /uploads/daily directory on the remote server, you’d first navigate to the correct remote directory:
Then, you’d use the put command to upload your local file:
The client will display the progress of the upload.
Uploading report.csv to /uploads/daily/report.csv
report.csv 100% 1024KB 10.2MB/s 00:00
To download a file from the server, you’d use the get command. For example, to download archive.zip from the remote /backups directory to your current local directory:
This whole process is secured by SSH. When you connect, SSH performs public-key cryptography to authenticate the server to the client and the client to the server (if configured). All data, including login credentials and the actual file content, is encrypted using SSH’s encryption algorithms. This is a fundamental difference from FTP, which transmits credentials and data in plain text, or FTPS (FTP over SSL/TLS), which adds a TLS layer to the FTP protocol but still relies on FTP’s underlying command structure.
The problem SFTP solves is the inherent insecurity of FTP. FTP was designed in an era where network security was a secondary concern. It sends usernames, passwords, and data unencrypted, making it trivial for an attacker on the same network to intercept sensitive information. SFTP, by leveraging SSH, encrypts everything. This means even if someone were to eavesdrop on the connection, they would only see gibberish.
The core of SFTP’s operation is its use of SSH channels. When you connect via SFTP, you’re actually establishing an SSH connection. Within that SSH connection, SFTP commands are sent as SSH protocol messages. The SSH server on the remote end then interprets these messages and performs the requested file operations. This means you get all the security benefits of SSH—authentication, encryption, and integrity—for your file transfers.
The primary levers you control with SFTP are authentication and access control. You can use password-based authentication, which is simple but less secure, or public-key authentication, which is far more robust. On the server side, you configure which users can connect, their home directories (often chrooted to prevent them from browsing the entire filesystem), and their read/write permissions on specific directories. For example, you might configure an SFTP server to only allow uploads to /var/sftp/uploads and downloads from /var/sftp/downloads, with each user chrooted to their own subdirectory within /var/sftp.
Most people think of SFTP as just a secure FTP, but its true power comes from its integration with SSH. This means you can often use the same SSH keys you use for logging into a server to authenticate your SFTP transfers, simplifying key management and enhancing security. The SFTP subsystem is typically started by the sshd daemon itself when a client requests SFTP functionality over an established SSH connection, rather than being a separate service that needs to be managed independently like an FTP server.
The next step in securing file transfers often involves implementing automated file synchronization or managed file transfer solutions.