Port 21 is a Security Hole: Configuring SFTP Chroot Jails on CentOS 5

If you are still using FTP in 2010, you are negligent.

I usually don't mince words, and I won't start now. If I run nmap against your IP block and see port 21 open, I assume your server is already compromised. It sounds harsh, but the reality of the Norwegian hosting market—and the internet at large—is that convenience is the enemy of security.

We have seen a massive uptick in packet sniffing attacks at the ISP level. With plain FTP, every single keystroke, including your username and password, is transmitted in cleartext. Anyone with access to a router between your workstation in Oslo and your server in the datacenter can read your credentials using a simple tool like Wireshark or tcpdump.

This isn't just bad practice; it is a potential violation of the Norwegian Personal Data Act (Personopplysningsloven). If you are handling customer data and you transmit it unencrypted, Datatilsynet will not be lenient if a breach occurs.

The Solution: SFTP (Not FTPS)

Many sysadmins confuse SFTP (SSH File Transfer Protocol) with FTPS (FTP over SSL). They are not the same.

• FTPS wraps the old FTP protocol in SSL. It is a nightmare to configure through firewalls because of the passive port range requirements.
• SFTP runs entirely over the SSH protocol (Port 22). One port, fully encrypted, simple firewall rules.

The historical objection to SFTP was that it gave users full shell access. You didn't want a web developer to have the ability to run rm -rf /. However, since OpenSSH 4.8 (standard in our CentOS 5 templates on CoolVDS), we have the ChrootDirectory directive. This allows us to lock a user into a specific folder without shell access.

Step-by-Step: Creating a Chrooted SFTP Jail

Let's assume you are running a standard RHEL/CentOS 5.5 environment. We will create a group for our SFTP users and configure the SSH daemon to restrict them.

1. Configure OpenSSH

Open your config file: /etc/ssh/sshd_config. You need to verify that you are using the internal SFTP subsystem. Some older configs point to /usr/libexec/openssh/sftp-server, which requires copying binaries into the jail. The internal-sftp simplifies this massively.

# Open /etc/ssh/sshd_config

# Comment out the old subsystem line
# Subsystem sftp /usr/libexec/openssh/sftp-server

# Use the internal subsystem
Subsystem sftp internal-sftp

Now, add the matching rules at the bottom of the file. This tells SSH: "If a user belongs to the group sftponly, lock them in their home directory and deny shell access."

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

Pro Tip: The ChrootDirectory MUST be owned by root and not writable by any other user or group. This is the most common reason for setup failure.

2. Create the User and Group

Now we create the group and a user. Let's say we have a client named "fjordclient".

# Create the group
groupadd sftponly

# Create the user with no shell access
useradd -d /var/www/vhosts/fjordclient -g sftponly -s /bin/false fjordclient

# Set a strong password
passwd fjordclient

3. Fix Permissions (The Critical Step)

As mentioned, the chroot root must be owned by root. Inside that, we create a writable folder for the user.

# Set ownership of the chroot jail root
chown root:root /var/www/vhosts/fjordclient
chmod 755 /var/www/vhosts/fjordclient

# Create the upload directory
mkdir /var/www/vhosts/fjordclient/html

# Give the user ownership of the inner directory
chown fjordclient:sftponly /var/www/vhosts/fjordclient/html
chmod 755 /var/www/vhosts/fjordclient/html

Now restart SSH:

service sshd restart

Performance Considerations: Encryption isn't Free

Moving from FTP to SFTP introduces overhead. Every byte transferred must be encrypted and decrypted. On a budget VPS where providers oversell the CPU (the "noisy neighbor" effect), you might see transfer speeds drop significantly compared to raw FTP. This is because the encryption calculation competes for CPU cycles.

This is where infrastructure choice matters. At CoolVDS, we utilize kernel-based virtualization (KVM) and Xen, ensuring strict CPU scheduling. Unlike OpenVZ containers where a neighbor's heavy PHP script can kill your SFTP throughput, our architecture guarantees the CPU cycles needed for high-speed encryption. If you are pushing gigabytes of data across the North Sea, that stability is vital.

Client-Side Configuration

For your Windows clients, instruct them to use WinSCP or FileZilla. In FileZilla, they must select "SFTP - SSH File Transfer Protocol" as the server type. If they try to connect via standard FTP, the server will correctly reject them.

Verification

Don't just hope it works. Test it. Try to SSH in as the user:

$ ssh fjordclient@your-server-ip
This service allows sftp connections only.
Connection to your-server-ip closed.

If you see that message, you have successfully secured your file transfer endpoint. You are no longer leaking passwords to the entire subnet.

Security is not a product; it is a process. But shutting down port 21 is a very good start.

Need a testing ground? Deploy a CentOS 5 instance on CoolVDS today. Our network is optimized for low-latency connections within the Nordics, ensuring your secure transfers are as fast as they are safe.