FTP is Dead: Securing Your File Transfers with SFTP and Chroot Jails

It is 2012. If you are still running a standard FTP daemon listening on port 21 without encryption, you are not just negligent; you are practically inviting an intrusion. I ran a quick tcpdump analysis on a client's legacy network last week. In less than five minutes, I captured three root passwords and a handful of database credentials being transferred in cleartext.

The standard File Transfer Protocol (FTP) was designed in an era where the internet was a friendly network of universities. It was never built for the hostile environment we face today. For those of us managing servers in Norway, compliance with the Personopplysningsloven (Personal Data Act) and the Data Protection Directive 95/46/EC means we cannot afford these leaks. If Datatilsynet (The Norwegian Data Inspectorate) audits your logs and finds cleartext transfers of personal data, the negligence argument won't hold up.

The solution isn't FTPS (FTP over SSL), which is often a firewall nightmare due to passive port ranges. The solution is SFTP (SSH File Transfer Protocol). It tunnels file transfers over your existing SSH connection, requires only port 22, and encrypts everything.

The Problem with Shell Access

The hesitation most admins have with SFTP is user isolation. Historically, giving someone SSH access meant they could browse your entire filesystem. You don't want your web developers poking around in /etc/ or seeing other clients' data.

This changed with OpenSSH 4.8p1, which introduced the ChrootDirectory directive. Now, on modern distributions like CentOS 6 or Debian 6 (Squeeze), we can lock users into a specific directory natively, without the messy hacks of the past (like copying /bin/ls and libraries into a jail).

Implementation: Configuring Chrooted SFTP

Let's assume you are running a standard CentOS 6.2 build on a CoolVDS instance. We will create a group for our SFTP users and lock them into their home directories.

1. Configure SSHD

Open /etc/ssh/sshd_config. You need to change the subsystem definition. Comment out the default request for the external sftp-server and use the internal one. The internal-sftp allows for chrooting without needing valid shell binaries inside the jail.

# /etc/ssh/sshd_config

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

# Use internal-sftp
Subsystem sftp internal-sftp

# Match the group we are about to create
Match Group sftponly
    ChrootDirectory %h
    ForceCommand internal-sftp
    AllowTcpForwarding no
    X11Forwarding no

2. Create the User and Group

Now we create the sftponly group and a user. A critical detail often missed is directory ownership. For ChrootDirectory to work, the directory owned by root must not be writable by the user. The user will upload into a subdirectory.

# Create the group
groupadd sftponly

# Create the user with no shell access
useradd -d /home/clientsite -g sftponly -s /sbin/nologin clientuser
passwd clientuser

# Fix permissions (CRITICAL STEP)
# The chroot root must be owned by root:root and not writable by the user
chown root:root /home/clientsite
chmod 755 /home/clientsite

# Create the upload directory
mkdir /home/clientsite/public_html
chown clientuser:sftponly /home/clientsite/public_html
chmod 755 /home/clientsite/public_html

If you fail the ownership step, /var/log/secure will scream about "bad ownership or modes for chroot directory" and the connection will drop instantly.

Performance: Encryption Overhead

Switching to SFTP does introduce overhead. Every packet is encrypted and decrypted. On legacy hardware or overloaded shared hosting, this can throttle throughput significantly. This is where the underlying architecture matters.

We benchmarked this on our CoolVDS platform versus a standard budget VPS. Because SFTP is CPU-bound regarding encryption, the processor speed defines your transfer rate.

Pro Tip: If you are transferring massive files and CPU is a bottleneck, you can tweak the cipher in your SSH client to arcfour or blowfish-cbc for faster speeds, though AES is the hardware-accelerated standard we are moving toward.

CoolVDS instances run on high-frequency enterprise processors that eat this encryption overhead for breakfast. Furthermore, because we use KVM virtualization, your encryption processes aren't fighting for CPU cycles with a "noisy neighbor" running a runaway PHP script. You get the dedicated throughput you pay for. Combined with our local peering at NIX in Oslo, latency is minimized, making the SSH handshake feel instantaneous.

Client-Side Configuration

You don't need fancy tools to connect. FileZilla and WinSCP handle this natively.

1. Host: sftp://your-server-ip
2. User: clientuser
3. Port: 22 (Default)

When the user logs in, they will land in /, which is actually /home/clientsite/ on the server. They cannot navigate up. They cannot see /etc/. They can only write to public_html. It provides the security of SSH with the isolation of FTP.

Troubleshooting with verbose logging

If your connection hangs, don't guess. Stop the service and run it in debug mode to see exactly where the handshake fails:

# Stop the service
service sshd stop

# Run in debug mode
/usr/sbin/sshd -d

You will often see permission errors regarding the chroot directory immediately. Once fixed, restart the service with service sshd start.

The Verdict

Plaintext FTP has no place in a professional environment in 2012. The risks of packet sniffing on public networks are too high, and the tools to secure it are already built into your Linux distribution. By leveraging the internal-sftp subsystem, you simplify your firewall rules (only port 22 needed) and ensure compliance with European data privacy standards.

Security requires resources. Don't let encryption overhead slow down your workflow. Deploy your secure SFTP gateway on a CoolVDS instance today, where high-performance SSD caching and dedicated CPU resources ensure your security doesn't come at the cost of speed.