Stop Broadcasting Your Root Password to the World

I watched a junior developer log into a production server via standard FTP at a coffee shop in Grünerløkka yesterday. I nearly knocked the latte out of his hand. In an era where packet sniffers are free and public Wi-Fi is ubiquitous, using FTP is effectively writing your credentials on a billboard.

It is 2009. We are seeing a massive spike in automated attacks like Gumblar which specifically harvest FTP credentials to inject malware into websites. If you are managing a VPS in Norway or handling client data, sticking to port 21 is negligence.

The Anatomy of Failure: FTP vs. SFTP

Let’s look at the wire. If you run a simple tcpdump while authenticating via standard FTP, this is what you see:

That is it. No encryption. No handshake masking. Anyone on the same subnet (or a compromised router node) has your keys to the kingdom. SFTP (SSH File Transfer Protocol), often confused with FTPS (FTP over SSL), runs entirely over the SSH protocol. It uses the same encryption tunnel you use for your terminal sessions.

Pro Tip: Do not confuse SFTP with FTPS. FTPS requires messy firewall port ranges for the data channel. SFTP uses a single port (22), making your firewall configuration on iptables incredibly clean.

Implementation: Locking Down OpenSSH

Historically, giving a user SFTP access meant giving them shell access. That terrified sysadmins. However, with the recent updates to OpenSSH (specifically versions 4.8+), we can now use the ChrootDirectory directive natively. No more hacking together restricted shells.

1. Configure sshd_config

Open /etc/ssh/sshd_config on your CoolVDS instance. We are going to tell SSH to use its internal SFTP subsystem rather than the external daemon, which allows for easier chrooting.

2. Match Group Constraints

At the bottom of the file, add a rule that catches anyone in the filetransfer group. This forces them into a specific directory and denies them shell access.

3. Permissions (The Tricky Part)

This is where most people break their setup. For the chroot to work, the directory owned by root must not be writable by the user. If your client is uploading to /home/client1/www:

• /home/client1 must be owned by root:root with permissions 755.
• /home/client1/www should be owned by client1:filetransfer.

The Latency Myth

I hear the complaint often: "Encryption adds overhead; SFTP is slower than FTP."

On a budget host overselling their CPU, maybe. But cryptography is CPU-bound. At CoolVDS, we run high-frequency Xeon processors and, crucially, we peer directly at NIX (Norwegian Internet Exchange). The latency between your Oslo office and our datacenter is often single-digit milliseconds. The encryption overhead is negligible compared to the risk of a data breach.

Compliance and the "Datatilsynet" Factor

Under the Norwegian Personal Data Act (Personopplysningsloven), you have a duty to secure sensitive data. Using cleartext protocols to transfer files containing personal information is a violation of these principles.

When you deploy on our infrastructure, you get full root access via Xen virtualization. We don't force a shared, insecure FTP service on you. You control the daemon. You control the keys.

Summary Checklist

Secure your workflow. Disable port 21 in your firewall today. If you need a sandbox to test your chroot configs without risking your production environment, spin up a CoolVDS instance. Our SAS RAID10 storage arrays ensure that even encrypted transfers saturate your bandwidth, not your I/O.