SFTP is often mistaken for FTPS, but it’s a fundamentally different beast that piggybacks on SSH, not its own TLS/SSL layer.
Let’s watch SFTP in action. Imagine a simple scenario: you need to upload a configuration file to a remote server.
# On your local machine
echo "This is my new config" > myapp.conf
# Connect and upload
sftp user@remote.server.com <<EOF
put myapp.conf /etc/myapp.conf
bye
EOF
This sftp command connects to remote.server.com as user, uploads myapp.conf from the current directory to /etc/myapp.conf on the remote server, and then disconnects. It’s concise and gets the job done.
The core problem SFTP solves is secure, reliable file transfer over untrusted networks. Before SFTP, protocols like plain FTP sent credentials and data in cleartext, making them trivial to intercept. FTPS (FTP over SSL/TLS) was an attempt to secure FTP, but it’s a bit of a kludge, often struggling with firewalls due to its use of multiple ports. SFTP, by contrast, leverages the established security of SSH (Secure Shell). SSH provides encryption, authentication, and integrity for the entire connection, and SFTP is simply a subsystem of SSH that handles file operations. This means SFTP typically uses only one port (the SSH port, usually 22), which dramatically simplifies network configuration and firewall rules.
Internally, when you initiate an SFTP connection, your client establishes a standard SSH connection. Once authenticated (via password, public key, etc.), the SSH daemon on the server recognizes an SFTP subsystem request and launches the SFTP server process. All subsequent file transfer commands (put, get, ls, rm, etc.) are sent as SSH messages, encrypted and authenticated by the underlying SSH tunnel. The SFTP server process on the remote end interprets these messages and performs the requested file operations. This tight integration with SSH is what gives SFTP its robustness and ease of deployment.
You control SFTP behavior primarily through SSH configuration and user permissions. The sshd_config file on the server dictates who can connect, how they authenticate, and what privileges they have. For fine-grained control over SFTP-only access (preventing users from getting a full shell), you can use the ChrootDirectory directive in sshd_config. This restricts a user’s filesystem view to a specific directory, making it impossible for them to navigate outside of it.
Match User sftp_only_user
ChrootDirectory /sftp/%u
ForceCommand internal-sftp
AllowTcpForwarding no
X11Forwarding no
In this example, sftp_only_user will be confined to /sftp/sftp_only_user and can only use SFTP, not a regular shell. The %u in ChrootDirectory expands to the username, creating a dedicated directory for each SFTP user.
The fact that SFTP is a subsystem of SSH means that commands like scp (Secure Copy) often use the same underlying SSH connection and authentication mechanisms. While scp is simpler for single file transfers, SFTP offers more advanced file management capabilities, like directory listings, renaming, and resuming interrupted transfers, all within the secure SSH tunnel.
The next hurdle you’ll likely face is managing SSH keys for automated SFTP transfers, especially when dealing with multiple remote servers.