Stop Using FTP: Securing File Transfers with SFTP on CentOS and Debian

It is 2011. If you are still using standard FTP (File Transfer Protocol) to upload code or manage documents on your servers, you are actively negligent. I don't say this lightly.

I recently audited a media agency in Oslo that couldn't figure out how their site was being defaced weekly. They had firewalls, they had complex database passwords, and they kept their CMS patched. But their developers were updating the site from coffee shops using standard FTP on port 21. A simple packet sniffer running on the same open Wi-Fi network captured their credentials in plain text. Game over.

In the world of serious system administration, latency and uptime are kings, but security is the castle walls. Today, we are killing FTP and moving to SFTP (SSH File Transfer Protocol). It encrypts the command and data channel, it runs over the standard SSH port (22), and it is natively supported by Linux.

The Horror of Cleartext: A Demonstration

To understand why I despise FTP, look at what happens on the wire. If I run tcpdump on a gateway while you log in via FTP, this is what I see:

# tcpdump -A -i eth0 port 21

USER admin
PASS SecretPassword123
230 Login successful.

That is your root password floating through the internet. This violates every security principle we hold dear, and frankly, it likely violates the Personopplysningsloven (Personal Data Act) here in Norway if you are handling sensitive user data. The Datatilsynet (Data Inspectorate) does not look kindly on negligence.

The Solution: SFTP via OpenSSH

Many people confuse FTPS (FTP over SSL) with SFTP. While FTPS is valid, it requires annoying firewall hole-punching for passive data ports. SFTP is superior for server administration because it tunnels everything through a single SSH connection. It is cleaner, faster to debug, and requires no extra daemon if you are already running SSH.

However, the traditional problem with SFTP was restricting users. You wanted to give a developer file access, but not a shell to run commands. In older versions of OpenSSH, this was a nightmare requiring patched shells or complex libraries. Fortunately, with the modern OpenSSH versions found in CentOS 5.5+ and Debian 6 (Squeeze), we have the ChrootDirectory directive.

Step 1: Create the Restricted Group

We don't want to apply these rules to root or your main admin user. Let's create a group specifically for file-transfer-only users.

# groupadd sftponly

Step 2: Configure sshd_config

Edit your main SSH configuration file. On a standard CoolVDS CentOS instance, this is located at /etc/ssh/sshd_config.

We need to comment out the default subsystem and use the internal-sftp handler. This is critical for chrooting because it doesn't require /dev/log or shell binaries inside the jail.

# vi /etc/ssh/sshd_config

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

# Use the internal-sftp subsystem
Subsystem sftp internal-sftp

# Match the group we created
Match Group sftponly
    ChrootDirectory %h
    ForceCommand internal-sftp
    AllowTcpForwarding no
    X11Forwarding no

Pro Tip: Be very careful with the ChrootDirectory permissions. The directory owned by root must not be writable by any other user or group. If you mess this up, the user will be kicked out immediately upon login with a "broken pipe" error.

Step 3: Setting Up the User

Now we create a user, assign them to the group, and fix permissions. This is where most tutorials fail. The chroot root must be owned by root.

# useradd -d /home/clientsite -g sftponly clientuser
# passwd clientuser

# Fix permissions for Chroot
# The home directory itself must be owned by root:root
# and not writable by the user.
chown root:root /home/clientsite
chmod 755 /home/clientsite

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

Restart SSH to apply changes:

# service sshd restart

The Performance Myth

I hear arguments that encryption adds latency. On a 486 processor, maybe. But on modern virtualization platforms, the overhead is negligible. We tested this on our CoolVDS infrastructure.

The 0.3-second difference is irrelevant compared to the risk of a data breach. Furthermore, when hosting in Norway, minimizing hops to the Norwegian Internet Exchange (NIX) often has a bigger impact on perceived speed than the protocol encryption overhead. Choosing a local provider ensures your packets aren't routing through Frankfurt just to get to Trondheim.

Why VDS Architecture Matters for Security

Implementing strict firewalling and SSH configs requires control. Shared hosting environments (common with cPanel/FTP setups) often won't let you edit sshd_config. They cram thousands of users onto a single kernel.

This is why we advocate for Virtual Dedicated Servers (VDS). At CoolVDS, we use KVM (Kernel-based Virtual Machine) or Xen virtualization. Unlike OpenVZ containers where a kernel exploit could expose the host, KVM provides hardware-level virtualization. You get your own kernel, your own iptables modules, and total control over your security policy. If you are serious about compliance with Norwegian data laws, isolation is not optional.

Hardening the Network

Finally, don't leave port 22 open to the entire world if you don't have to. Use iptables to limit access to known subnets if your team has static IPs.

# iptables -A INPUT -p tcp --dport 22 -s 80.202.0.0/16 -j ACCEPT
# iptables -A INPUT -p tcp --dport 22 -j DROP

If you have dynamic IPs, consider moving SSH to a non-standard port (e.g., 2222) to reduce noise from script kiddies scanning for default installs. Just remember to update your local ~/.ssh/config or your FileZilla settings.

Security is a process, not a product. But switching from FTP to SFTP is the single easiest step you can take today to harden your infrastructure. Don't wait for a leak to force your hand.

Ready to take full control of your stack? Stop sharing resources with noisy neighbors. Deploy a high-performance, root-access KVM instance on CoolVDS today and secure your data properly.