FTP is Dead: Securing File Transfers with Chrooted SFTP on CentOS 6

If you are still running an FTP daemon listening on port 21 in late 2012, you aren't just taking a risk—you are practically broadcasting your credentials to the world. I still see developers FTPing into production servers from unsecured coffee shop Wi-Fi networks in Grünerløkka, oblivious to the fact that a simple packet sniffer can capture their root password in cleartext.

With the increasing scrutiny from Datatilsynet (The Norwegian Data Protection Authority) regarding the handling of personal data under the Personal Data Act, relyng on outdated protocols is no longer an option. It is a liability.

In this guide, we are killing legacy FTP. We will replace it with SFTP (SSH File Transfer Protocol), specifically configuring a Chrooted Jail so your developers can upload files without seeing the rest of your filesystem. We will do this using standard tools available on CoolVDS KVM instances running CentOS 6 or Ubuntu 12.04 LTS.

The Anatomy of a Disaster: Why Port 21 Must Die

Traditional FTP was designed in an era where the internet was a friendly network of universities. It has no encryption. None. When you authenticate, your username and password flow over the wire as plain text.

Pro Tip: Do not believe me? Run tcpdump port 21 -w capture.pcap on your server while you login via FTP. Open that file in Wireshark. Your password will be right there in the 'USER' and 'PASS' command frames.

SFTP is not "FTP over SSH." It is a completely different protocol that runs over the SSH subsystem. It benefits from the same strong encryption (AES, Blowfish) as your shell sessions. For those hosting in Norway, this is the baseline for "adequate security measures" required by law.

Step-by-Step: configuring Chrooted SFTP

Many sysadmins shy away from SFTP because historically, chrooting users (locking them into a specific folder) was a nightmare of copying /bin/bash and libraries into a jail. Since OpenSSH 4.9, we have the internal-sftp subsystem, which makes this trivial.

1. Prepare the Group and User

First, we create a group for our file-transfer-only users. This allows us to apply specific sshd rules to them without affecting your root access.

# groupadd sftponly
# useradd -g sftponly -s /bin/false -d /var/www/vhosts/client_site deploy_user
# passwd deploy_user

Note that we set the shell to /bin/false. These users should never get a shell prompt.

2. Configure SSHD

Open your ssh configuration file. On a standard CoolVDS CentOS 6 instance, this is located at /etc/ssh/sshd_config.

Find the line referring to the sftp subsystem (usually utilizing /usr/libexec/openssh/sftp-server) and comment it out. Replace it with the internal subsystem:

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

Next, append the logic to handle our sftponly group at the very bottom of the file:

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

3. The Critical Permissions Trap

This is where 99% of configurations fail. For ChrootDirectory to work, the directory must be owned by root and not writable by any other user or group. If the permissions are wrong, SSH will reject the connection immediately to prevent security bypasses.

Here is the correct structure for a web server setup:

# Set the chroot directory ownership
chown root:root /var/www/vhosts/client_site
chmod 755 /var/www/vhosts/client_site

# Create the writable content directory INSIDE the chroot
mkdir /var/www/vhosts/client_site/public_html
chown deploy_user:sftponly /var/www/vhosts/client_site/public_html
chmod 755 /var/www/vhosts/client_site/public_html

Now, when deploy_user logs in, they will land in / (which is actually /var/www/vhosts/client_site) and they can only write into the public_html folder.

4. Restart and Verify

Reload the SSH daemon to apply changes. Do not disconnect your current root session until you have verified access in a new terminal!

# CentOS / RHEL
service sshd reload

# Debian / Ubuntu
service ssh reload

Performance: The CoolVDS Advantage

Encryption adds overhead. On a generic, oversold VPS with high CPU steal time, switching from FTP to SFTP can drop your transfer speeds significantly because the CPU is struggling to encrypt the data stream. This is where infrastructure matters.

At CoolVDS, we don't oversell our cores. We use KVM virtualization, ensuring that the AES instruction sets (AES-NI) on our host processors are passed through to your instance. This hardware acceleration means your encrypted transfers happen at near wire-speed.

Furthermore, for Norwegian businesses, latency is a security feature. When you are managing servers via SSH, you need instant feedback. Our datacenter's direct peering with NIX (Norwegian Internet Exchange) ensures that your keystrokes are registered instantly.

Final Thoughts on Compliance

Under the current interpretation of the Personal Data Act, you are responsible for securing the transit of sensitive data. If a client uploads a CSV of customer emails via FTP and it gets sniffed, that is on you.

Moving to SFTP isn't just a technical upgrade; it's a business necessity. It reduces your attack surface by closing port 21 completely and leverages the battle-tested OpenSSH daemon.

Don't let legacy protocols compromise your infrastructure. Deploy a secure, high-performance CentOS instance on CoolVDS today and lock down your file transfers before your next audit.