1. SFTP and the SSH File Transfer Protocol
The SSH File Transfer Protocol, commonly known as SFTP, is a network protocol for transferring and managing files between a client and a server through SSH. Its name often causes confusion. Despite including the letters FTP, SFTP is not a secure version of the classic File Transfer Protocol. It is a separate protocol used through the Secure Shell (SSH) connection, with its own request and response messages.
Classic FTP sends credentials and file content as clear text unless another protection layer is added, and it uses separate control and data connections. In common implementations, SFTP operates over one SSH connection. The SSH stack establishes encryption and integrity protection, while SSH user authentication verifies the user for that connection. SFTP also provides file-system operations such as listing, renaming, and permission changes, which makes it suitable for interactive and automated file management.
The alternative secure protocol, , is a direct extension of the original FTP. SFTP, in contrast, is a distinct file-transfer protocol used as an SSH subsystem within an SSH-2 connection. SFTP specifications have been published as IETF Internet-Drafts; those drafts are expired and have neither RFC nor Internet Standard status. Implementations may also provide vendor extensions. The SSH transport and connection protocols are defined by the SSH standards. The appropriate choice depends on server support, client support, and the security policy of the environment.
2. SFTP Through Secure Shell
SFTP uses the security services of its underlying SSH connection. Secure Shell is a cryptographic network protocol for operating network services over an unsecured network. After negotiation and successful verification, it provides confidentiality, user and host authentication, and integrity protection for SFTP traffic:
- Confidentiality and encryption
After the algorithms are negotiated, SSH encrypts the traffic between the client and the server. This prevents a passive observer from reading login credentials, file content, and commands. It uses strong algorithms such as AES for bulk data transfer.
- Authentication
SSH authenticates the server with a host key and authenticates the user with a method accepted by the server. Host-key verification prevents a man-in-the-middle attack only when the expected key or fingerprint is checked, rather than accepted blindly. User authentication can use a password or, more securely for many deployments, .
- Integrity
The SSH transport verifies the integrity of transmitted data and detects modification in transit. Depending on the negotiated cipher, each packet is protected with a or with an authenticated-encryption mode that combines confidentiality and integrity.
SFTP operates as a subsystem within an established SSH connection. After the SSH channel is created and the user is authenticated, the SFTP protocol is started over that channel. SFTP commands and data become payload carried by SSH, so their confidentiality and integrity depend on the negotiated SSH protection and the correctness of host-key verification.
3. SFTP Architecture: One SSH Connection
A common SFTP deployment uses one SSH connection for the complete file-management session, unlike FTP and FTPS, which separate control and data connections.
A Single Port, a Single Connection
In this deployment, the initial connection, authentication, commands, replies, and file data transfers use one TCP connection. SSH uses port 22 by default, but an administrator can configure another port.
This single-port architecture provides several key benefits:
- Firewall Friendliness: A firewall can permit SFTP by allowing the configured SSH port, commonly port 22. FTP and FTPS require the control port (21) and data connections, including a range of ports in passive mode, which makes the rules more complex and can increase the exposed surface.
- Reduced Overhead: Establishing TCP connections takes time and resources. A persistent connection avoids repeatedly opening and closing data connections for each file transfer, which can improve performance for many small files. Actual throughput still depends on latency, window sizes, and the implementation.
- Packet-Based Protocol: SFTP is packet-based rather than text-command-based like FTP. Commands and data are sent in binary-formatted packets, with explicit lengths and fields. Requests can be pipelined, so multiple requests may be outstanding before replies arrive, subject to the client and server limits.
SFTP Clients and Servers
OpenSSH servers commonly expose an SFTP subsystem, provided that the subsystem is installed and enabled. OpenSSH is available on many Linux, macOS, and current Windows installations, but availability still depends on the server software and its configuration. Common SFTP client applications, such as FileZilla, WinSCP, and Cyberduck, provide graphical interfaces for interacting with SFTP servers.
4. Key Capabilities of SFTP
SFTP provides a set of file-management operations that support remote administration and automated transfer tasks.
- File Transfers: The primary function, allowing for secure uploading and downloading of files.
- Directory Listing: Listing the contents of remote directories.
- Directory Management: Creating ('mkdir'), deleting ('rmdir'), and navigating ('cd') remote directories.
- File Deletion: Removing remote files ('rm').
- File Renaming: Renaming files and directories on the server.
- Permission and Attribute Modification: Changing file permissions (e.g., using 'chmod') and modifying timestamps.
- Resuming Transfers: The protocol natively supports resuming interrupted file transfers from the point of failure.
- Symbolic Links: Creating and reading symbolic links on the remote file system.
5. The SFTP Authentication Process
SFTP authentication is handled by SSH user authentication. Two common methods are:
Password Authentication
This is the simplest method. The user provides a username and password, which the SFTP client sends inside the SSH user-authentication exchange. After the SSH host key has been verified, encryption protects the password from passive network observation, unlike standard FTP. The server checks the credentials against its account and authentication policy. Password login remains exposed to guessing and requires rate limits and strong passwords.
Public Key Authentication
This method does not send a password over the network. It uses a cryptographic key pair and a signature tied to the SSH session:
- Key Generation: The user first generates a key pair on their local machine, consisting of a private key, protected against unauthorized access, and a corresponding public key that can be installed on the server.
- Public Key Installation:The user copies their public key and places it in a specific file (typically '~/.ssh/authorized_keys') on the server in their user account. The public key is designed to be shared.
- Authentication Request:When the client connects, it tells the server that it wishes to use a public key. The server checks whether the corresponding key is allowed in 'authorized_keys' and accepts a test request before the signed authentication request.
- Client Signature:The client's software uses the user's private key, which never leaves the client's machine, to sign session-specific authentication data and sends the signature to the server.
- Verification:The server uses the public key it already has to verify the signature. Since only the corresponding private key could have created a valid signature for that public key, the server can confirm the client's identity without ever seeing a password.
Public-key authentication is common for automated, server-to-server file transfers. It avoids password guessing against the account, but the private key still needs access control, protection with a passphrase where appropriate, and a policy for revocation.
6. Comparison: SFTP vs. FTPS vs. SCP
| Feature | SFTP (SSH File Transfer Protocol) | FTPS (FTP over SSL/TLS) | SCP (Secure Copy Protocol) |
|---|---|---|---|
| Underlying Protocol | SSH | FTP with SSL/TLS Layer | SSH |
| Number of Connections | One (SSH default port 22) | Two (Control and Data) | One (SSH default port 22) |
| Firewall Friendly? | Yes, when one SSH port is allowed. | More complex, because data ports must also be allowed. | Yes, when one SSH port is allowed. |
| File Management | Rich (list, delete, rename, etc.) | Rich (inherits from FTP) | Basic (file transfer only) |
| Resuming Transfers? | Yes, natively supported. | Supported through FTP REST and client/server support. | Not part of the classic copy model. |
| Primary Use Case | Interactive and automated secure file management. | Securing legacy FTP environments. | Simple, scripted, non-interactive secure file transfer. |