FTP is Dead: Why Plain Text Transfers Are Suicide in 2011

I still see it. Every single day. I run a tcpdump on a client's edge router, and there it is: port 21 traffic flowing in the clear. In an era where firesheep can hijack sessions in a coffee shop and WEP cracking is child's play, using standard FTP is professional negligence. If you are managing servers in Norway, you aren't just risking your uptime; you are risking the wrath of Datatilsynet (The Norwegian Data Inspectorate).

We are done with excuses. Moving to SFTP (SSH File Transfer Protocol) isn't "future-proofing" anymore; it is the bare minimum requirement for August 2011. Unlike FTPS (FTP over SSL), which is a firewall nightmare involving a mess of passive ports, SFTP rides strictly over port 22. It is clean, it is encrypted, and if you configure it right, it is just as restrictive as a traditional FTP jail.

The Anatomy of a Disaster: Why FTP Fails

Let's look at why I hate standard FTP daemons like vsftpd or ProFTPD when used without TLS. The protocol was written in 1971. It predates the modern internet. When you authenticate, your username and password traverse every switch and router between you and the server in plain ASCII.

Here is what a script kiddie sees when you login to your "secure" server via FTP:

USER admin
PASS Hunter2

That's it. Your server is compromised. If you are hosting on CoolVDS, we provide robust KVM isolation, but we can't patch stupidity. You need to secure the transport layer.

The Fix: Native Chrooted SFTP in OpenSSH

Historically, chrooting SFTP users was a pain. You had to copy /bin/bash, libraries, and /dev nodes into the jail. It was messy and prone to breaking on updates. However, recent versions of OpenSSH (starting from 4.9, which is standard on our CentOS 6 and Debian Squeeze templates) utilize the internal-sftp subsystem to handle this effortlessly.

This method locks a user into their home directory without giving them shell access. They can upload files, but they cannot snoop around /etc/ or run top to spy on your load averages.

Step 1: Configure sshd_config

Open your main SSH configuration file. Always back it up first.

cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
vi /etc/ssh/sshd_config

Find the line defining the Subsystem (usually near the bottom) and change it. We are switching from the external server to the internal one, which does not require support files inside the chroot.

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

Step 2: Create the Restriction Group

We don't want to chroot everyone (you still need root access). We will apply rules based on a group.

groupadd sftponly

Step 3: Apply the Match Block

Append the following to the very end of /etc/ssh/sshd_config. This tells SSH: "If the user is in the 'sftponly' group, lock them in their home directory and force them to use SFTP."

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

Restart SSH to apply changes. Do not exit your current root session until you verify you can still log in!

service sshd restart

Permissions: The Tricky Part

This is where 90% of admins fail. For ChrootDirectory to work, the directory must be owned by root and not writable by any other user. The user cannot own their own chroot root.

Let's set up a user named client1:

useradd -g sftponly -s /bin/false client1
passwd client1

# Fix permissions for the jail
chown root:root /home/client1
chmod 755 /home/client1

# Create a writable directory INSIDE the jail
mkdir /home/client1/public_html
chown client1:sftponly /home/client1/public_html
chmod 755 /home/client1/public_html

Pro Tip: If the user cannot login and you see "broken pipe" errors in your logs, verify the ownership of the chroot directory. It must be root:root. This is a security requirement of OpenSSH to prevent privilege escalation via hardlinks.

Latency, NIX, and Performance

Some argue that the encryption overhead of SSH makes SFTP slower than FTP. In 2001, maybe. In 2011, with modern CPUs, this is negligible. The real bottleneck is network latency. SSH is a chatty protocol; it requires multiple round-trips for handshakes.

This is where hosting location matters. If your dev team is in Oslo and your server is in Texas, SFTP will feel sluggish. By hosting on CoolVDS, you are peering directly at NIX (Norwegian Internet Exchange). The latency between your office in Fornebu and our data center is likely under 5ms. At that speed, SFTP feels instantaneous. You get security without the wait.

Compliance and The "Personopplysningsloven"

Under the Personal Data Act (Personopplysningsloven) of 2000, you are responsible for securing the processing of personal data. If you are transferring customer databases or logs via cleartext FTP, you are likely in violation of Section 13 regarding information security.

Don't wait for a data breach to learn this lesson. The shift to SFTP is free, takes five minutes to configure, and significantly hardens your infrastructure.

Final Verification

Test your setup from a local machine using the command line:

sftp client1@your-coolvds-ip
# You should land in /
# You should see public_html
# You should NOT be able to cd ..

If that works, you are ready. Stop using legacy protocols. Upgrade your security posture today.

Need a sandbox to test your security configs? Spin up a CoolVDS instance in 55 seconds and get root access instantly.