Stop Using FTP: Securing File Transfers with SFTP and Chroot on Linux

The 21st Century Called: It Wants Its Protocol Back

If you are still typing ftp into your terminal or configuring port 21 in your firewall, stop. Seriously. It is July 2011, and we have better tools.

As a systems administrator who has spent too many nights cleaning up compromised web servers after the Gumblar attacks, I have zero tolerance for clear-text protocols. When you use standard FTP, you are broadcasting your username and password to every hop between your workstation and the server. If you are sitting in a coffee shop in Oslo using open Wi-Fi, anyone with a copy of Wireshark can harvest your credentials in seconds.

For businesses operating in Norway, this isn't just bad practice; it borders on violating the Personal Data Act (Personopplysningsloven). The Datatilsynet (Data Protection Authority) expects you to take "reasonable measures" to secure data. Sending root passwords over the wire in plain text is not reasonable.

This guide will walk you through burying FTP and replacing it with SFTP (SSH File Transfer Protocol), specifically configured to lock users into their home directories (Chroot) on a CentOS 6 or Debian Squeeze system. This is the standard configuration we deploy on all managed CoolVDS instances.

Why SFTP Beats FTPS and FTP

Many people confuse SFTP with FTPS (FTP over SSL). They are not the same.

• FTP/FTPS: Requires opening multiple ports (Control port 21, plus a massive range for PASV connections). It is a firewall nightmare.
• SFTP: Runs entirely over the SSH protocol (Port 22). One stream, fully encrypted, simple firewall rules.

From a latency perspective, connecting to our nodes in Oslo via SFTP is snappy. There is no three-way handshake dance for a data channel like in FTP. It is a single encrypted tunnel.

The Horror: Seeing It in Action

Don't believe me? Here is what it looks like when I sniff traffic on a server while someone logs in via standard FTP. I ran tcpdump on the interface facing the public internet:

# tcpdump -i eth0 -n -A port 21

14:20:11.829102 IP 192.168.1.50.5678 > 85.x.x.x.21: Flags [P.], seq 1:15, ack 1, win 65535, length 14
USER admin

14:20:11.929102 IP 192.168.1.50.5678 > 85.x.x.x.21: Flags [P.], seq 15:28, ack 1, win 65535, length 13
PASS MySecret123

There it is. MySecret123. If that was your root password, your server is now part of a botnet. On a CoolVDS high-performance SSD VPS, we disable standard FTP by default in our templates for exactly this reason.

Configuration: Chrooting SFTP Users

The main argument for FTP was always, "I don't want to give my web developer full shell access." You don't have to. With OpenSSH 5.x (standard on CentOS 6), we can use the internal-sftp subsystem to restrict users to a specific directory without shell access.

Step 1: Configure sshd_config

Open your SSH configuration file. We need to tell SSH to use its internal SFTP handler rather than the external binary, which simplifies the chroot environment significantly.

# vi /etc/ssh/sshd_config

# Find this line and comment it out:
# Subsystem sftp /usr/libexec/openssh/sftp-server

# Add this line instead:
Subsystem sftp internal-sftp

# At the very bottom of the file, add the Match block:
Match Group sftponly
    ChrootDirectory %h
    ForceCommand internal-sftp
    AllowTcpForwarding no
    X11Forwarding no

Pro Tip: The ChrootDirectory %h directive tells SSH to lock the user into their home directory. The ForceCommand internal-sftp prevents them from running commands like ls, bash, or cp via SSH. They can only transfer files.

Step 2: Create the Group and User

We need a group for these users, and strict permission handling. The directory owned by root must not be writable by the user, or the chroot will fail (a security feature of OpenSSH).

# Create the group
groupadd sftponly

# Create a user 'webdev' with no shell access, added to the group
useradd -d /var/www/coolsite -s /sbin/nologin -g sftponly webdev

# Set a password
passwd webdev

Step 3: Fix Permissions (The Tricky Part)

This is where 90% of admins fail. For Chroot to work, the directory defined in ChrootDirectory (in this case /var/www/coolsite) must be owned by root and writable only by root. The user can then upload to a subdirectory inside it.

# 1. The Chroot root must be owned by root
chown root:root /var/www/coolsite
chmod 755 /var/www/coolsite

# 2. Create a folder for uploads that the user CAN write to
mkdir /var/www/coolsite/public_html
chown webdev:sftponly /var/www/coolsite/public_html
chmod 755 /var/www/coolsite/public_html

# 3. Restart SSH to apply changes
service sshd restart

Now, when user webdev logs in, they land in /, which is actually /var/www/coolsite. They cannot go up a level. They can only upload files into public_html.

Hardening the Firewall

Since we are dumping FTP, we can close port 21. On a standard Linux node (CentOS/RedHat), use iptables. Keeping open ports to a minimum is essential for low-latency performance; you don't want your CPU cycles wasted on processing SYN floods on unused ports.

# List current rules
iptables -L -n

# Allow SSH (Port 22) - Make sure this is enabled!
iptables -A INPUT -p tcp --dport 22 -j ACCEPT

# Drop FTP (Port 21)
iptables -A INPUT -p tcp --dport 21 -j DROP

# Save rules
service iptables save

Why Infrastructure Matters

Implementing SFTP encryption adds a small amount of CPU overhead compared to plain FTP. On older, oversold VPS hosts, you might see transfer speeds drop because the physical CPU is choking on encryption/decryption.

This is where CoolVDS architecture shines. We don't oversell our cores. Whether you are using Xen or KVM virtualization, our nodes in Norway utilize high-speed RAID-10 storage and enterprise-grade Intel Xeon processors that handle AES encryption instructions natively. You get the security of SFTP with transfer speeds that saturate your uplink.

Migration Checklist

Final Thoughts

Security is not about convenience; it is about discipline. Moving from FTP to SFTP is one of the easiest wins you can get for your infrastructure's security posture. It keeps your developers happy, your auditors satisfied, and your data safe from prying eyes at the internet exchange.

If you need a testing ground to try out these Chroot configurations without risking your production environment, spin up a CoolVDS instance. With our instant provisioning, you can have a fresh CentOS 6 box ready for testing in under 60 seconds. Don't let legacy protocols be your downfall.