The operation of any IT infrastructure involves the need to transfer files between nodes, whether from a local machine to a server and back, or between environments or servers. And almost always, when transferring files over a network, there is a risk of data interception or leakage, especially if configuration errors occur. Moreover, this isn’t limited to sensitive data like backups or configurations containing secrets. Even the transfer of seemingly ordinary files - such as uploading a website or downloading logs - can become an entry point for an attack on your infrastructure if your communication channel isn’t secured. Add the human factor to the mix, and the risk ceases to be hypothetical. If someone sets incorrect permissions, uses weak passwords, or leaves unnecessary ports open, you can consider your server compromised.
For a long time, standard FTP was used for file transfers. It is a simple and intuitive tool supported almost everywhere. But from a security standpoint, this solution belongs to a bygone era. The fact is that FTP transmits data in plain text, meaning all your usernames, passwords, and file contents are sent as-is. You can think of file transfer via FTP as sending a secret letter without an envelope, where anyone who happens to be “along the way” can read everything you’ve written.
SFTP (SSH File Transfer Protocol) solves this problem without unnecessarily complicating your infrastructure. It doesn’t require a separate service, doesn’t force you to open additional ports, and doesn’t add unnecessary points of failure. Instead, it uses an existing SSH connection and embeds file transfer into it, so all your traffic is encrypted by default.
As you’ve probably already realized, SFTP is file transfer over SSH (Secure Shell), a protocol specifically designed for secure connections.
Key Differences Between FTP, SFTP, and FTPS
Currently, three protocols are most commonly used for file transfer: FTP, SFTP, and FTPS. But there is an architectural difference between these protocols that significantly distinguishes them from one another in terms of information security.
It is clear that all three solve the same problem - transferring files over a network - but they do so in different ways. Standard FTP is a classic data transfer protocol that operates without encryption. It is very simple, but, unfortunately, quite vulnerable. FTPS attempted to add a layer of security by wrapping standard FTP in a secure SSL/TLS connection, while retaining its complex model with multiple connections. Unlike the first two, SFTP takes a different approach. It is built from the ground up on top of SSH and operates as a single secure channel.
This leads to differences not only in security but also in configuration and behavior - for example, which ports are used, how authentication works, how difficult it is to configure a firewall, and how the connection behaves in real-world network environments.
Therefore, before choosing a protocol for a specific task, it is important to understand this difference not just in terms of terminology, but in terms of how they work. Below, we have attempted to provide a concise comparison of these three protocols in the form of a simple comparison table, which helps you quickly see the differences and understand for which tasks a particular tool is appropriate.
| Protocol | Encryption | Ports | Authentication | Setup Complexity | Best Use Cases |
|---|---|---|---|---|---|
| FTP | No | 21 + dynamic | Login/password | Low | Internal networks without security requirements, temporary test environments, legacy systems |
| FTPS | Yes (SSL/TLS) | 21 + dynamic | Login/password | Medium | Integrations with enterprise systems (e.g., banks, legacy ERP) where TLS is required but FTP compatibility is needed |
| SFTP | Yes (SSH) | 22 | Keys / password | Low | DevOps and production infrastructure, backups, deployments, file exchange between servers, unstable networks and NAT environments |
How SFTP works under the hood
Internally, it’s fairly simple, as it’s based on standard SSH. The client establishes a secure connection with the server, goes through authentication, and then the SFTP subsystem launches.
Commands like ls, put, get (more details below) are not regular shell commands that run on the server system. These are operations of the SFTP protocol itself, which are transmitted and processed within the secure connection.
Simply put, when working via SFTP, you do not gain access to the remote server’s command line. You interact with the file system through a set of predefined actions, such as listing files, uploading, downloading, or deleting.
However, security addresses most potential concerns. Encryption is symmetric, keys are asymmetric, and data exchange uses verified algorithms; therefore, if the server is configured correctly, intercepting data is virtually impossible.
It is also important to understand that SFTP is not an add-on in the usual sense, but rather a separate subsystem within a standard SSH server. In OpenSSH, this subsystem is called internal-sftp. And when a client connects, the server can either grant it a full shell or immediately “lock” it within the SFTP environment without the ability to execute commands. This feature is actively used to restrict access to the server, for example, for clients or contractors who only need access to files but should not be able to execute commands on the server.
From a network interaction perspective, everything also looks quite neat, since unlike FTP and FTPS, which use multiple connections (control + data), SFTP operates over a single TCP connection. This greatly simplifies things when working behind NAT, through a firewall, or in cloud infrastructures.
But of course, as with everything, SFTP also has its downsides. One such downside is buffering when working with files, where SFTP breaks the transfer into packets and processes them sequentially. This certainly makes it more reliable, but sometimes slower compared to more straightforward tools like SCP. On the other hand, with unstable connections, SFTP behaves much more predictably and is less likely to drop the transfer.
What encryption algorithms are used
As we mentioned above, SFTP inherits everything from SSH. Therefore, in a typical configuration, the following protocols are used:
- AES-256 - which is currently the de facto standard for encryption;
- ChaCha20 - this protocol runs faster on systems with outdated and weak CPUs;
- ED25519 - a modern key algorithm.
Additionally, two more protocols are used during the connection process:
- ECDH (Elliptic Curve Diffie-Hellman) - used for secure key exchange;
- HMAC (e.g., hmac-sha2-256) - used to verify data integrity.
In other words, we see that this isn’t just some form of encryption, but a fully mature stack, proven over the years through numerous audits and real-world attacks. And in most cases, it is much more secure than any homemade security layer built on top of an insecure protocol. Besides, why reinvent the wheel?
Preparing and Configuring SFTP on the Server
To get started with SFTP on a Linux server, in most cases you don’t need to install anything extra, since if SSH is already running on the server, SFTP will work as well. By default, access is enabled without any restrictions, but to make SFTP truly secure and convenient, we need to tweak it a bit.
Our task is to create a separate user for file operations and assign them their own dedicated directory, to which their access will be restricted, without the ability to log into the system via the shell.
Let’s start by creating the user:
sudo adduser sftpuser
Next, we need to prepare the directory, and this is where one of the most common mistakes occurs: incorrect permissions are set for this directory, causing SFTP to either fail to start at all or operate insecurely. The directory where the user will be “confined” must belong to root:
sudo mkdir -p /home/sftpuser/uploads
sudo chown root:root /home/sftpuser
sudo chmod 755 /home/sftpuser
The inner folder where the user will upload files is assigned to them:
sudo chown sftpuser:sftpuser /home/sftpuser/uploads
Next, we need to configure SSH itself. Open the file /etc/ssh/sshd_config, and add the following block at the end:
Match User sftpuser
ChrootDirectory /home/sftpuser
ForceCommand internal-sftp
X11Forwarding no
AllowTcpForwarding no
With these instructions, the user is restricted to a single directory, does not have access to the command line, and can only use SFTP.
After changing the configuration, all that remains is to restart the SSH server:
sudo systemctl restart ssh
Now you can test the connection from a remote computer:
sftp sftpuser@server_ip
If everything is configured correctly, the user will be inside their directory and will not be able to leave it. At the same time, they will not have access to the shell, but will have access exclusively to the files within that directory.
In practice, this is sufficient for most tasks. We have achieved simple and secure file access without unnecessary customizations or excessive complexity.
Key-based authentication
After the basic SFTP configuration, it makes sense to address another important aspect right away: authentication. As you saw in the previous example, password authentication is used by default, but this is the weakest link in the chain, because even complex passwords are highly susceptible to brute-force attacks, leaks, and simple human error.
The problem can be solved by using key pairs instead of a password.
To do this, generate a key on your workstation, which you will use to connect to the server:
ssh-keygen -t ed25519
By default, the keys are saved in ~/.ssh/. Usually, it’s enough to just press Enter at every step, but if you wish, you can set a passphrase - additional protection for the private key.
Next, you need to transfer the key to the remote server using the command:
ssh-copy-id user@server_ip
This command will automatically add the public key to the ~/.ssh/authorized_keys file on the server and set the necessary permissions. After that, you can immediately test the connection, which will no longer require a password.
If ssh-copy-id is unavailable, you can do the same manually by simply copying the contents of the file ~/.ssh/id_ed25519.pub and adding it to ~/.ssh/authorized_keys on the server.
Once key-based authentication is working, it’s best to disable password authentication entirely. To do this, in /etc/ssh/sshd_configchange the parameter:
PasswordAuthentication no
Then restart the SSH service again:
sudo systemctl restart ssh
IMPORTANT! Only restart the SSH service after verifying the keys; otherwise, you may lose access to the server.
That’s essentially all the configuration. Now let’s move on to the SFTP commands themselves.
Basic commands for working with SFTP
Once you’ve connected to the remote server via SFTP, you’ll enter an interactive environment for working with files. The commands here are simple, but it’s important to understand that some of them operate on the remote system, while others operate on your local system. Below we list the most frequently used commands and briefly describe what they do.
ls- displays a list of files and directories on the server. Can be used with flags (for example,ls -l) for more detailed output;cd- changes the current directory on the server;put- uploads a file from the local machine to the server (for example,put file.txt);get- downloads a file from the server to the local machine;put -r- uploads an entire directory along with its contents;get -r- downloads a directory from the server recursively;lcd- changes the current directory on the local machine (local cd);mkdir- creates a new directory on the server;rm- deletes a file on the server;
This set is quite sufficient for performing most tasks, such as uploading website files to the server, transferring backups, working with logs, and so on. The remaining commands are used much less frequently and usually depend on the specific client. You can find a complete list of commands in any available manual, for example here.
Graphical Clients
Obviously, not everyone finds it convenient to work via the terminal, especially when it comes to transferring a large number of different files. In such cases, it is much easier to use a graphical client, which is essentially the same SFTP, but with the familiar Windows Explorer interface.
SFTP is supported by almost all popular clients, such as FileZilla, WinSCP, Cyberduck, and others. From the user’s perspective, connecting in these clients looks the same as connecting to a regular FTP server, with the difference that you need to select the SFTP protocol from the dropdown menu instead of FTP. Then, when configuring the connection, you specify the same basic parameters:
- Host - the IP address or domain of the remote server;
- Port - the standard SSH port 22 or the one you specified in the SSH settings on the remote server;
- User - username;
- Key file - the path to the private key, if you are using key-based authentication.
After connecting, the familiar interface opens, divided into two windows: local files on the left, server files on the right. You can simply drag and drop files with the mouse, as well as copy, delete, and rename them. In other words, all the same features are available as in the console, only without the need to memorize commands.
Limitations and Pitfalls
Of course, SFTP is a convenient and secure tool, but unfortunately, it is not universal. And in some scenarios, it may be inferior to other solutions, which is worth considering in advance when planning your work.
First, as we mentioned at the beginning of the article, its weak point is data transfer speed, since SFTP operates carefully, with data verification and buffering, which is why it sometimes falls short in performance compared to more straightforward tools like plain SCP. This difference is usually not critical, but it can be quite noticeable when transferring large files.
Second, the lack of parallelism, since SFTP does not support multithreaded data transfer at the protocol level. While some clients work around this limitation using their own methods, this is part of their internal implementation rather than a feature of SFTP itself.
And finally, the need to pay special attention to access permissions, since incorrect configuration of directory permissions can result in a user seeing more than they should, and in the event that a malicious actor gains access to that directory - the possibility of privilege escalation all the way up to root. Admittedly, this isn’t a problem with SFTP itself, but rather a matter of diligence when configuring and administering the server.
Overall, these nuances don’t make SFTP a bad choice - it’s just important to understand its capabilities and the limits of its application.
To simplify things, the choice between the most popular tools might look like this:
- SFTP - a versatile option for secure file transfer. It’s convenient, easy to understand, and suitable for most tasks;
- SCP - faster due to its simplicity, but less flexible, which is why it has recently been gradually fading into the background;
- rsync - the best choice for incremental synchronization and backups, as it transfers only changes rather than entire files, which can significantly save on traffic.
In practice, as usual, it all depends on the specific task. If you simply need to transfer files from one device to another, SFTP fully addresses this need. But if speed or traffic optimization is important to you, then it makes sense to look into alternatives.
SFTP FAQ
How does SFTP differ from FTP?
SFTP encrypts all traffic - including logins, commands, and file contents. In contrast, FTP transmits data in plain text, which is why its use on the internet is considered insecure.
Are SFTP and FTPS the same thing?
No, they are different protocols. FTPS is classic FTP with SSL/TLS encryption added on top, while SFTP is built directly on top of the SSH protocol and operates as a single secure channel.
What port does SFTP use?
By default, port 22 is used - the same as for SSH. This simplifies configuration, as no additional ports need to be opened.
Can SFTP be used without SSH?
No, SFTP does not exist independently of SSH. It is a subsystem of SSH that operates within a secure connection.
How secure is SFTP?
When using SSH keys and with proper server configuration, SFTP is considered very secure. It protects not only the data but also the transfer process itself from interception.
Which to choose: SFTP, SCP, or rsync?
SFTP is suitable for most tasks where simplicity and security are needed. SCP is faster but less flexible, while rsync is best used for synchronization and transferring only changed data.
Why doesn’t SFTP allow you to execute commands on the server?
Because SFTP is a protocol for working with files, not remote access to the system in the full sense. It is intentionally limited to enhance security and reduce the risk of errors.
Conclusions
So, we’ve established that SFTP is a logical extension of what’s already available on any Linux server, namely the SSH protocol. To use it, you don’t need to install any additional services, open extra ports, or perform any complex configuration - you simply get a high-quality, secure channel for file transfer.
Of course, some configuration is still worth doing. For example, by creating a separate user for file transfers, restricting access rights to the working directory and setting its owner (chroot), as well as configuring key-based authentication - you turn SFTP into a reliable and isolated tool for working with files.
That said, it’s important to understand its limitations. It isn’t the fastest or the most advanced in terms of synchronization. But for most practical tasks, such as deploying applications, taking backups, and simple file sharing, it fully meets all requirements.
And that is precisely why this tool is being used more and more often, as ease of configuration, predictable performance, and security are what are valued above all else in a real-world infrastructure.
