Kill Port 21: The Definitive Guide to SFTP Chrooting on CentOS 6

If you are still running a standard FTP daemon (vsftpd, ProFTPD, or Pure-FTPd) on port 21 without explicit TLS encapsulation, you are negligent. There is no polite way to say this.

I was recently auditing a server for a mid-sized e-commerce shop in Oslo. They were complaining about "strange file modifications" in their web root. Within ten minutes of `tcpdump` analysis, the culprit was obvious. Their lead developer was updating the site from a public coffee shop WiFi network using plain FTP. Every single credential was broadcast in cleartext across the network.

In 2012, with the sophistication of packet sniffers like Wireshark and the ubiquity of unsecured public networks, relying on FTP is a fireable offense. It violates best practices, and more importantly, it puts you at odds with the Norwegian Personal Data Act (Personopplysningsloven) if you are handling sensitive customer data.

The solution is not FTPS (which is a firewall nightmare due to passive port ranges). The solution is SFTP (SSH File Transfer Protocol). Specifically, chrooted SFTP using the `internal-sftp` subsystem in OpenSSH.

Why SFTP is the Only Logical Choice

Unlike FTP, SFTP is not a separate protocol wrapping a shell. It is a subsystem of SSH. It runs over Port 22 (or your custom SSH port), uses a single TCP connection, and benefits from the exact same strong encryption (AES-256, usually) as your shell sessions.

For a System Administrator, the benefits are immediate:

• One Hole in the Firewall: No need to open port 21 plus a massive range (e.g., 30000-50000) for PASV connections.
• Key-Based Auth: You can enforce RSA key authentication and disable passwords entirely.
• Native Chrooting: Since OpenSSH 4.9, we can lock users to their home directories without setting up complex `/dev` nodes or copying libraries (the old jail hell).

Pro Tip: When moving clients from shared hosting to a dedicated VPS, latency matters. SFTP is slightly chatty compared to stream-based protocols. Hosting your infrastructure on CoolVDS in Norway ensures that the Round Trip Time (RTT) to your local developers is minimized, making file transfers feel instantaneous rather than sluggish. High latency kills the SFTP experience.

Step-by-Step: Configuring Chrooted SFTP on CentOS 6.2

Let's assume you have a clean CoolVDS instance running CentOS 6. We are going to create a group for file-transfer-only users, ensure they cannot get a shell, and lock them into a specific directory.

1. Create the Group and User

First, create a group called `sftponly` and a user. We set the shell to `/bin/false` so they cannot login via SSH terminal.

groupadd sftponly
useradd -g sftponly -s /bin/false -d /home/clientsite client_user
passwd client_user

2. Configure sshd_config

Open your SSH configuration file. This is the surgical part. We need to tell OpenSSH to use the internal subsystem and apply specific rules to our new group.

vi /etc/ssh/sshd_config

Find the line that configures the `sftp-server` (usually the default) and comment it out. Replace it with `internal-sftp`. This allows us to use Chroot without copying system binaries into the user's folder.

#Subsystem sftp /usr/libexec/openssh/sftp-server
Subsystem sftp internal-sftp

Now, append the following block to the very bottom of the file. The `Match Group` directive is powerful, but it applies to everything following it, so keep it at the end.

Match Group sftponly
    ChrootDirectory %h
    ForceCommand internal-sftp
    AllowTcpForwarding no
    X11Forwarding no

3. The Permissions Trap (Crucial)

This is where 90% of admins fail, resulting in a "Connection Closed" error immediately upon login.

The Rule: For `ChrootDirectory` to work, the directory specified (in our case `%h`, which is `/home/clientsite`) must be owned by `root` and not writable by any other user or group.

If the user can write to the chroot root, they could theoretically exploit the SUID binary setup to break out of the jail. OpenSSH protects you from this by refusing to connect if permissions are wrong.

Here is the correct permission structure:

# Lock the home directory
chown root:root /home/clientsite
chmod 755 /home/clientsite

# Create a writable upload directory INSIDE
mkdir /home/clientsite/public_html
chown client_user:sftponly /home/clientsite/public_html
chmod 755 /home/clientsite/public_html

Now, the user logs in and lands in `/`. They can see `public_html` and write inside it, but they cannot delete the root folder or wander up the tree to `/etc`.

4. Restart and Test

Reload the SSH daemon to apply changes:

service sshd reload

Test it from a local machine:

$ sftp client_user@your-coolvds-ip
client_user@your-coolvds-ip's password: 
Connected to your-coolvds-ip.
sftp> pwd
Remote working directory: /
sftp> cd ..
sftp> pwd
Remote working directory: /

If you see the above, the jail is working.

Performance Considerations: Cipher Overhead

One argument I often hear from the "Pragmatic CTO" types is that encryption adds CPU overhead. "We have terabytes of video logs, SSH is too slow."

In 2004, maybe. In 2012, this is nonsense. Modern CPUs handle AES instructions effortlessly. The bottleneck is rarely the CPU; it is the I/O of your storage subsystem.

At CoolVDS, we use enterprise-grade SSD storage arrays. When you are pushing thousands of small PHP files via SFTP (a common Magento or Drupal deployment scenario), the random write performance of SSDs obliterates traditional SAS 15k drives. The encryption overhead of SFTP is mathematically insignificant compared to the wait time of a mechanical drive seeking sectors.

Legal & Compliance: The Norwegian Context

Operating in Norway means adhering to strict standards. The Data Inspectorate (Datatilsynet) takes a dim view of unsecured data transmission. Under the Personal Data Act of 2000, you are required to implement "satisfactory technical and organizational measures" to secure personal data.

If you transfer customer databases or logs containing PII (Personally Identifiable Information) over port 21, you are failing that requirement. If a breach occurs and the forensic audit reveals cleartext FTP usage, your negligence will be a primary factor in any fines issued.

Conclusion

There is no excuse for running an FTP server in 2012. It is an artifact of a simpler, safer internet that no longer exists. SFTP offers better security, easier firewall management, and with `internal-sftp`, it is simple to configure.

Don't let your infrastructure be the low-hanging fruit for script kiddies. Secure your transport layer.

Ready to lock down your stack? Deploy a high-performance SSD VPS on CoolVDS today. Our infrastructure is located in Norway, optimized for low latency, and built for professionals who value security.