1. Overview
OpenSSH is a suite of secure networking tools that provides encrypted communication and authentication between hosts. It’s one of the most popular implementations of SSH and SFTP. It consists of components such as sshd (server daemon), ssh (client), scp (secure copy client), and sftp (secure file transfer client).
SFTP enables users to securely transfer files over a network using SSH as the underlying transport layer. It offers advantages over other file transfer protocols. For instance, SFTP uses a single port (22) for both data and control channels. This simplifies firewall configuration and reduces security risks. Notably, SFTP also supports various file attributes, such as permissions, timestamps, and symbolic links. These preserve the integrity and metadata of the files.
However, OpenSSH provides two subsystems that handle SFTP requests from clients: internal-sftp and sftp-server. A subsystem is a program that runs on the server side and communicates with the client via the SSH protocol. The subsystem can be specified in the sshd_config file or in the command line when invoking sshd.
In this tutorial, we’ll discuss the differences between internal-sftp and sftp-server and when we should use one over the other.
2. internal-sftp
internal-sftp is a configuration keyword that tells the OpenSSH sshd to use an in-process SFTP server built into the sshd binary. This means sshd doesn’t need to run an external process (such as sftp-server) to handle SFTP requests. Rather, it uses its own code to do so.
Using internal-sftp has some advantages over using sftp-server. One advantage is simplicity. We don’t need to install or maintain a separate binary for the sftp-server. However, this is at the price of flexibility. internal-sftp doesn’t allow customization or fine-grained control over SFTP behavior or parameters.
To configure internal-sftp in the sshd_config configuration file, we use the Subsystem directive with the keyword internal-sftp:
Subsystem sftp internal-sftp
We can also use the ForceCommand directive with the keyword internal-sftp to force all SSH connections to use SFTP.
3. sftp-server
sftp-server is a standalone binary implementing the SFTP file transfer subsystem. In fact, sftp-server is invoked as an external process by sshd when an SFTP session is requested by a client.
Depending on the system, we’re most likely to find this subsystem binary in one of two places:
- /usr/lib/openssh/sftp-server
- /usr/libexec/openssh/sftp-server
To find the location of the sftp-server binary, we can use the locate command:
$ locate sftp-server
sftp-server allows customization over the SFTP behavior via command-line arguments or environment variables. For instance, we can limit the maximum number of concurrent requests or enable logging by passing appropriate arguments to sftp-server.
To set sftp-server in the sshd_config configuration, we again use the Subsystem directive but with the path to the sftp-server binary:
Subsystem sftp /usr/lib/openssh/sftp-server
Naturally, we can use the ForceCommand directive with the path to the sftp-server binary to force all SSH connections to use only SFTP.
4. Comparison
Let’s compare internal-sftp and sftp-server in terms of functionality, security, and performance.
4.1. Functionality
internal-sftp and sftp-server are almost identical in terms of functionality. They both implement the same protocol and support the same features. They’re also built from the same source code, so they should behave consistently and reliably.
However, there’re some minor differences that may affect some edge cases. For instance, internal-sftp doesn’t involve a login shell in any way, while sftp-server does. This means that internal-sftp bypasses any shell configuration or restrictions that may apply to some users:
- aliases
- environment variables
- login scripts
Even though internal-sftp supports the same options as sftp-server, internal-sftp may not support some features in older versions of OpenSSH. Therefore, sftp-server should be a better choice when interacting with systems that rely on older SSH versions.
4.2. Security
Security is another crucial factor to consider when choosing between internal-sftp and sftp-server. Both subsystems provide encryption, authentication, and integrity features via the SSH protocol.
However, internal-sftp can be used with the ChrootDirectory directive. This allows us to restrict SFTP users to a specific directory on the server. It enhances the security and isolation of the users, as they can’t access or modify any files outside the chroot directory.
Also, internal-sftp doesn’t require any external files or binaries to function. This reduces the attack surface and the risk of compromise. For instance, if an attacker gains access to the sftp-server binary or modifies it, they may be able to execute arbitrary code or commands on the server. This binary file may also have vulnerabilities or bugs that could compromise the system.
Notably, sftp-server supports logging SFTP activity to a file or syslog for auditing and monitoring purposes. This can help detect or prevent unauthorized or malicious actions.
4.3. Performance and Scalability
Performance and scalability are important factors to consider when choosing between internal-sftp and sftp-server. Depending on the workload and environment, one subsystem may perform better than the other.
internal-sftp doesn’t need to run an external process for each SFTP session. Rather, it uses an in-process SFTP server built into the sshd binary. This means that internal-sftp avoids the overhead of creating and managing a new process for each SFTP session, which improves efficiency and resource utilization. Also, internal-sftp doesn’t rely on external files or binaries to function, which reduces disk space and memory usage.
However, benchmarking and performance testing are essential to determine the optimal subsystem for a given scenario.
5. Use Cases and Recommendations
Depending on the requirements and preferences, internal-sftp or sftp-server may be more suitable for different scenarios:
internal-sftp is recommended for scenarios where security and isolation are important, such as chrooting users to a specific directory. For instance, a web hosting company will want to use internal-sftp to provide secure file transfer services to its customers. It’ll chroot each customer to their own web directory and restricts their access to other files or directories on the server.
sftp-server is preferred for complex and flexible SFTP setups that require advanced features or customization. It’s also the choice for scenarios where compatibility is important. This includes supporting more SFTP features or extensions or handling large-scale deployments or high-traffic environments.
6. Conclusion
In this article, we’ve seen what internal-sftp and sftp-server are and how they work. Moreover, we’ve compared them in terms of functionality, security, and performance.
internal-sftp has some advantages over sftp-server in terms of simplicity, performance, and compatibility with the ChrootDirectory directive. However, sftp-server is suitable for scenarios where backward compatibility or logging is needed.