Table of Contents
Understanding FTP and SFTP
FTP and SFTP are both used to transfer files between systems over a network, but they work in very different ways and offer very different levels of security. As an administrator, you will often manage at least one of them on servers that provide file access to users or applications.
What FTP Is
FTP stands for File Transfer Protocol. It is one of the oldest application protocols on the internet and was designed to allow users to upload and download files to and from a remote server.
FTP is a client server protocol. A user runs an FTP client that connects to an FTP server. The user authenticates, usually with a username and password, and then interacts with a remote filesystem. Common operations include listing directories, changing directories, uploading, downloading, renaming, and deleting files.
FTP uses two separate TCP connections. One connection is called the control connection and is used for commands and responses. The other connection is called the data connection and is used to actually transfer file contents and directory listings.
FTP normally uses port 21 for the control connection. The port used for the data connection depends on whether the server and client are operating in active mode or passive mode.
Active vs Passive FTP
In active mode, the client connects from an arbitrary high port to the server port 21 to establish the control connection. When it is time to transfer data, the client opens a listening port on its side and tells the server the IP address and port. The server then initiates a connection back to the client from its port 20 to that client port.
This behavior is often a problem with firewalls and NAT, because many client side firewalls or routers do not allow incoming connections from the server to the client. Active mode tends to fail in such environments unless special firewall rules or helpers are configured.
In passive mode, the client still connects to the server on port 21 for the control connection. When data needs to be transferred, the client asks the server for a passive port. The server opens a listening port on its side in a configured passive range and tells the client which IP and port to use. The client then connects to that server port from a high client port.
Passive mode works better through firewalls and NAT because both connections are initiated by the client. On the server side, you must configure the passive port range and open those ports in the firewall.
For FTP to work reliably across networks with firewalls, passive mode is usually required, and the passive port range must be explicitly opened on the FTP server firewall.
Security Characteristics of FTP
Traditional FTP transmits everything in cleartext. Usernames, passwords, commands, directory listings, and file data all travel unencrypted over the network. Anyone who can observe the traffic can read the credentials and contents.
Because of this, plain FTP is considered insecure on untrusted networks. It is sometimes still used on trusted local networks or for anonymous downloads from public mirrors, but even in those cases it is often replaced by HTTP, HTTPS, or SFTP.
To improve FTP security, two approaches exist:
- FTP over explicit TLS (often called FTPS). The client connects using normal FTP semantics and then negotiates a TLS session for encryption and integrity.
- FTP over implicit TLS. The client connects to a dedicated port, traditionally 990, where TLS is assumed from the beginning.
These variants provide encryption similar to HTTPS. They are still FTP in design, so they keep the separate control and data connections and the complexity of active and passive modes. Configuration of FTPS behind firewalls is often more complex than SFTP because of these multiple connections.
What SFTP Is
SFTP stands for SSH File Transfer Protocol. Despite the name, SFTP is not FTP running over SSH. It is a separate protocol that was designed to work over an SSH connection. Administrators frequently confuse these concepts, so it is important to be precise.
SFTP runs inside the same encrypted channel that SSH uses. When an SFTP client connects to an SFTP server, it is actually opening an SSH session on port 22 by default, authenticating with SSH username and password or SSH keys, and then requesting the SFTP subsystem. The SFTP protocol then uses this single SSH connection for commands and data.
From the user perspective, SFTP looks similar to FTP. You can list remote directories, change directories, upload, download, and manage files. Many FTP clients also support SFTP and present it in the same interface. Under the hood, however, SFTP is stateful and binary and does not use separate TCP connections or negotiate active or passive modes.
SFTP always uses SSH encryption and always uses a single TCP connection, typically on port 22, for both control and data.
Key Differences Between FTP and SFTP
The most important difference is security. FTP is cleartext by default. SFTP is fully encrypted because it uses SSH for transport. Any user credentials and transferred data are protected when you use SFTP.
Another practical difference is port usage and connection handling. FTP uses at least two connections and requires careful firewall configuration, especially for passive ports. SFTP uses one connection to port 22, the same port commonly used for SSH remote login, which is usually already open on servers.
Authentication is also handled differently. FTP usually uses local user credentials specific to the FTP daemon or real system accounts. It can be integrated with other auth systems, but this is implementation dependent. SFTP directly uses SSH authentication methods. These include passwords, public key authentication, and possibly two factor methods integrated into SSH.
At the protocol level, FTP is text based. It uses human readable commands such as LIST, RETR, and STOR. SFTP uses structured binary messages defined by versions of the SFTP protocol. This does not usually affect basic server administration, but it is important for tool developers.
As an administrator, the main result of these differences is that SFTP is usually simpler to secure. You rely on SSH configuration for encryption, keys, ciphers, and login policies. With FTP, you must manage TLS certificates, encryption settings, and often special firewall helpers for state tracking of control and data channels.
When to Use FTP
Despite security drawbacks, FTP is still used in some scenarios. Public file distribution is the most common example. Many open source projects historically served downloads over FTP mirrors that allowed anonymous login. In practice, HTTP and HTTPS have largely replaced FTP in this role, but some legacy setups remain.
FTP is also sometimes used internally where legacy automation or devices only support FTP. Embedded systems, old copy machines, or industrial equipment may only implement FTP for sending or receiving files. In such cases, the network is usually restricted and controlled, and the FTP server may only be reachable from specific subnets.
If you must deploy FTP, consider using FTPS with TLS. This provides confidentiality and integrity, though it can be more complex to configure. Ensure that firewalls, passive port ranges, TLS certificates, and logging are all configured correctly.
When to Use SFTP
Whenever you need secure file transfer to a multi user Linux server, SFTP is usually the best choice. Existing SSH infrastructure can be reused for authentication and access control. Users can authenticate with SSH keys, which are more secure and easier to automate than passwords.
SFTP is also convenient for administrators. If SSH is already configured and secured, enabling SFTP access is often just a matter of confirming that the SFTP subsystem is available in the SSH server configuration. File permissions and ownership on the server filesystem continue to be enforced by the kernel and standard Unix permission model.
Applications and scripts can use SFTP libraries to move data securely between servers. Because SFTP uses a single port and single connection, it behaves predictably across different network environments and through NAT.
Basic Administrative Concepts for FTP Servers
Several FTP daemons are available on Linux, such as vsftpd, proftpd, and pure-ftpd. Each has its own configuration style, but they share common concepts.
An FTP server configuration usually specifies which network interfaces and ports to listen on. Port 21 is standard for the control connection. When passive mode is used, the configuration defines a range of ports, for example 40000 to 50000, that the server will open for data connections. Firewalls must allow incoming connections to this port range from FTP clients.
The server configuration also defines authentication methods. Some FTP servers allow anonymous access, where no password is required for a specific directory tree. Others restrict access to named users. These named users can be real system accounts or virtual users that are only known to the FTP daemon and mapped to internal UIDs.
Chrooting is another common feature. A chrooted FTP user is restricted so that their root directory appears to be a particular directory on the server, such as /srv/ftp/users/alice. They cannot navigate above this directory. This is often used to prevent users from seeing or accessing other parts of the filesystem through FTP.
Access control rules are important. Many FTP daemons allow you to specify which users or groups may log in via FTP, which addresses are allowed or denied, and what file permissions are enforced on uploaded files. Transfer limits, such as maximum parallel connections, per user bandwidth, and global bandwidth, can also be configured.
Logging is usually configurable. FTP logs typically include user logins, uploads, downloads, and errors. These logs are important for troubleshooting and auditing, particularly when many users interact with the server.
Basic Administrative Concepts for SFTP
On most Linux distributions, SFTP is provided by the OpenSSH server. When you install and enable the SSH server, SFTP support is usually available automatically. The SFTP subsystem is defined in the SSH server configuration file, typically /etc/ssh/sshd_config, by a line such as:
Subsystem sftp /usr/lib/ssh/sftp-serverOr, on some systems, using the internal implementation:
Subsystem sftp internal-sftpFor ordinary users, SFTP is accessed with the same credentials they use for SSH login. Their SFTP session will have the same home directory and the same Unix permissions. This means that file access through SFTP is governed by standard user, group, and permission settings that you already manage on the system.
Administrators often want users to have SFTP access without allowing them full SSH shell access. This can be implemented with SSH configuration features that restrict users to the internal-sftp subsystem and place them in a chroot jail. In that mode, users can only transfer files and cannot run arbitrary commands.
Just like for SSH, SFTP benefits from SSH key-based authentication. Users can generate key pairs and upload their public keys to the server in ~/.ssh/authorized_keys. Automated processes can then use keys instead of storing passwords in scripts.
SSH configuration controls which ciphers, key types, and KEX algorithms are allowed for SFTP. Keeping these modern and secure is part of hardening SSH for file transfer. You can also use Match blocks in sshd_config to apply special settings to particular users or groups that only use SFTP.
Logging for SFTP sessions is handled by the SSH daemon. You can adjust logging verbosity with SSH options such as LogLevel and examine logs in the system log files. These logs will show SFTP logins, disconnects, and errors related to the SSH session.
Interoperability and Client Tools
Clients that speak FTP often also support SFTP, but they treat them as separate protocols. When you configure such a client, you must choose which protocol to use and provide appropriate connection settings, including host, port, username, and authentication method.
Graphical file transfer applications on Linux, macOS, and Windows usually provide both FTP and SFTP options. Popular editors and IDEs also have SFTP integration, so developers can edit files on remote Linux servers over SFTP directly.
On the command line, traditional ftp clients are used for FTP. For SFTP, the sftp client that ships with OpenSSH provides an interactive environment to navigate and transfer files. Some automation scripts use scp instead, which is also SSH based, but SFTP is more flexible and better suited for scripting robust transfers.
When planning services, ensure that users know which protocol to use. If your server offers both FTP and SFTP with the same hostname, document the correct ports and security expectations. In general, encourage SFTP for any access over untrusted networks.
Migration from FTP to SFTP
Many organizations move from FTP to SFTP to improve security and simplify firewall rules. Migration usually involves enabling SSH and SFTP on the server, configuring accounts and permissions, and then updating client configurations.
Because SFTP uses Unix users and permissions directly, you often need to review existing FTP user mappings. Virtual FTP users that were stored in an FTP specific database might need to be replaced with real system accounts or re-created in a different way. Directory structures may stay the same, but SFTP users will need read and write permissions at the filesystem level.
Automation scripts that talk to FTP may need to be rewritten using SFTP libraries or command line tools. This provides an opportunity to also replace password based logins with SSH keys. While there is some initial effort, the resulting system is usually simpler to secure and maintain.
If legacy clients cannot be updated to SFTP, you might run FTP and SFTP side by side, but restrict FTP to specific networks or devices. Over time, you can phase out FTP as dependencies are removed.
By understanding the conceptual differences and typical deployment patterns of FTP and SFTP, you can choose the right protocol for your environment and manage file transfer services in a secure and maintainable way.