FTP is Dead: Securing Your Data Transfer with SFTP on Linux

It is 2012. If you are still running a standard FTP daemon (vsftpd, proftpd, or pure-ftpd) listening on port 21 without TLS, you are not just negligent; you are begging to be compromised. I recently audited a client's infrastructure in Oslo—a mid-sized e-commerce shop running Magento. They complained about "phantom files" appearing in their web root. It took me exactly five minutes to diagnose the breach.

They had developers uploading code via standard FTP from public Wi-Fi networks. Someone sniffed the traffic, grabbed the cleartext credentials, and injected a PHP shell. Game over.

In the Norwegian market, where Datatilsynet (The Data Protection Authority) actively enforces the Personopplysningsloven (Personal Data Act), security isn't just a technical requirement; it's a legal one. If you are hosting sensitive customer data on a VPS, you cannot afford cleartext protocols.

Today, we are killing FTP. We are moving to SFTP (SSH File Transfer Protocol). Not FTPS (FTP over SSL), which is a firewall nightmare, but SFTP—which runs over the robust, encrypted SSH protocol you already use.

The Horror of Port 21

To understand why this is urgent, look at what happens when you log into a standard FTP server. If an attacker is on the same network, they can simply run tcpdump.

# Attacker's machine
tcpdump -i eth0 -A port 21

The output is terrifyingly readable:

USER admin
PASS s3cr3tP@ssw0rd
230 Login successful.

That is your root password flying across the wire. This is why at CoolVDS, we often see customers migrating from shared hosting environments—where FTP is often the only option—to our dedicated VPS solutions where they can enforce proper encryption standards.

Configuring Chrooted SFTP on Ubuntu 12.04 LTS / CentOS 6

The goal is to allow a user to upload files securely, but prevent them from getting a shell via SSH. We also want to lock them (chroot) into their home directory so they can't browse your system files (like /etc/passwd).

OpenSSH 5.x and later supports the ChrootDirectory directive natively. Here is how we configure it. This setup works perfectly on the standard images provided by CoolVDS.

1. Create the SFTP Group and User

First, we create a group specifically for these users. This allows us to apply the configuration globally to anyone in this group.

groupadd sftponly
useradd -m -g sftponly -s /bin/false developer1
passwd developer1

Note: We set the shell to /bin/false so they cannot log in via a standard SSH terminal session.

2. Configure SSHD

Edit your ssh config file. I recommend vim /etc/ssh/sshd_config.

Find the line that configures the Subsystem (usually near the bottom) and comment out the default. Replace it with the internal-sftp subsystem, which does not require external binaries inside the chroot jail.

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

Next, append the following block to the very end of the file:

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

3. The Critical Permission Fix

This is where 90% of admins fail. For ChrootDirectory to work, the directory owned by root must not be writable by the user. The user's home directory (%h) is usually owned by the user, which causes SSH to reject the connection immediately.

We must change the ownership of the home directory to root, and create a subdirectory for uploads.

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

# Create the upload directory
mkdir /home/developer1/public_html
chown developer1:sftponly /home/developer1/public_html

Pro Tip: If you see "Connection closed" immediately upon login, check your /var/log/auth.log (Ubuntu) or /var/log/secure (CentOS). It almost always complains about "bad ownership or modes for chroot directory".

4. Reload SSH

service ssh reload
# OR for CentOS
service sshd reload

Performance: The Encryption Overhead Myth

A common argument from the shared hosting crowd is that SFTP is slower than FTP because of the encryption overhead. In 2002, this might have been true. In 2012, even a modest CPU can handle AES encryption at wire speed.

However, latency plays a role. The SSH protocol is "chatty." Each packet requires acknowledgement. If your server is in the US and you are in Oslo, that latency stacks up, effectively throttling your transfer speed. This is why CoolVDS locates its infrastructure directly in Datacenters with direct peering to the NIX (Norwegian Internet Exchange). By keeping the server physically close to your dev team in Norway, we reduce RTT (Round Trip Time) to under 10ms, making SFTP transfers feel instantaneous.

Using Keys for Password-less Auth

To truly secure the setup, disable password authentication entirely and force key-based auth. On your local machine (Linux/Mac):

ssh-keygen -t rsa -b 2048 -f ~/.ssh/id_rsa_coolvds

Copy the public key to the server. Since we disabled shell access for the user, you'll need to do this as root manually:

mkdir -p /home/developer1/.ssh
echo "ssh-rsa AAAAB3... (your public key) ..." >> /home/developer1/.ssh/authorized_keys
chown -R developer1:sftponly /home/developer1/.ssh
chmod 700 /home/developer1/.ssh
chmod 600 /home/developer1/.ssh/authorized_keys

Now, your developers can use clients like FileZilla or WinSCP, point the key file in the settings, and connect securely without ever typing a password.

Why Infrastructure Matters

Implementing SFTP is a software change, but the reliability of that connection depends on your host. Traditional shared hosting environments often limit the number of concurrent SSH connections or throttle encrypted traffic to save CPU cycles for other tenants.

At CoolVDS, we allocate dedicated resources via Xen virtualization. Whether you use the latest SSD storage for database performance or high-capacity RAID arrays for backups, the CPU cycles required for encryption are yours to use. You get the security of a dedicated server with the flexibility of the cloud.

Don't wait for a data breach to explain to Datatilsynet why you were using a protocol from 1985. Secure your infrastructure today.

Ready to lock down your stack? Spin up a CoolVDS instance in Oslo and start transferring data securely in under 60 seconds.