Stop Broadcasting Your Root Password to the World

It is 2011. If you are still using standard FTP (Port 21) to manage your servers, you might as well print your root password on a billboard in downtown Oslo. I recently audited a client's infrastructure—a mid-sized e-commerce shop hosting on a budget provider. They were baffled as to how their index.php kept getting injected with iframe malware. The culprit wasn't a zero-day exploit in their kernel. It was a developer logging in via FTP from a coffee shop Wi-Fi network. Packet sniffer caught the cleartext credentials. Game over.

As systems administrators, we have a responsibility to kill legacy protocols that compromise infrastructure. With the Norwegian Personal Data Act (Personopplysningsloven) and the watchful eye of Datatilsynet, data leakage isn't just an IT headache; it's a legal liability. The solution is simple, robust, and already installed on your server: SFTP via OpenSSH.

FTP vs. SFTP: The Protocol Gap

Don't confuse FTPS (FTP over SSL) with SFTP (SSH File Transfer Protocol). FTPS is a firewall nightmare that requires opening a passive port range (often 10,000+ ports) to the public. SFTP uses a single port: 22. It is encrypted by default, binary-safe, and piggybacks on the rock-solid SSH daemon.

The "Chroot" Challenge

Historically, the main argument against SFTP was that giving a user SSH access meant giving them shell access. You didn't want your web designer poking around /etc/. Since OpenSSH 4.9, however, we have the internal-sftp subsystem and ChrootDirectory directive. This locks users into their home folders without shell access.

This is crucial for agencies managing multiple clients on a single VPS. You need isolation. If you are running CentOS 5.5 or Ubuntu 10.04 LTS, you have the tools to do this right now.

Implementation: Configuring the Jail

Here is the battle-tested configuration we use for client setups. This assumes you are running a standard RHEL/CentOS or Debian-based system.

First, edit your SSH daemon config:

Find the default Subsystem line and comment it out. Replace it with the internal version:

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

Next, add a matching block at the bottom of the file to trap specific users. I recommend creating a group called sftponly:

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

Critical Warning: The directory specified in ChrootDirectory (in this case %h, the user's home) must be owned by root and not writable by any other user. If permissions are wrong, the user will be kicked out immediately upon login. The structure should look like this:

Pro Tip: Don't restart SSH blindly. Use sshd -t to test your configuration syntax first. If you mess up port 22 on a remote server without a KVM console, you are locking yourself out. Good providers offer an emergency console, but it's better not to need it.

Performance: Encryption Overhead?

A common myth is that the encryption overhead of SFTP slows down transfers compared to FTP. In 2005, maybe. In 2011, even a modest VPS with decent CPU allocation handles the AES encryption without breaking a sweat. The bottleneck is almost always disk I/O or network latency, not the CPU.

This is where infrastructure choice matters. If you are on a crowded node where the host oversells resources, your "steal time" (CPU wait) will spike during transfers. At CoolVDS, we strictly limit tenants per node and utilize Enterprise-grade RAID-10 SAS storage (and are currently testing early SSD caching implementations). This ensures that when you push a 500MB update via SFTP, the disk writes keep up with the network stream.

The Local Angle: Latency & Law

For Norwegian businesses, hosting data outside the EEA (European Economic Area) is becoming increasingly complex legally. Keeping your server in Oslo or nearby European hubs ensures you fall squarely under the 95/46/EC Directive framework, simplifying compliance with local authorities.

Furthermore, SFTP is chatty. It requires multiple round-trips for acknowledgments. If your server is in Texas and your dev team is in Trondheim, latency kills your transfer speeds. Hosting locally with CoolVDS slashes that latency to single-digit milliseconds, making file management feel instant.

Final Thoughts

FTP had a good run (since 1971!), but in an era of public Wi-Fi and sophisticated packet sniffing, it is a liability you cannot afford. Switching to SFTP requires five minutes of configuration and zero additional cost.

If your current host doesn't give you the root access needed to modify sshd_config, or if their network is too slow for encrypted protocols, it's time to move. Spin up a root-access VPS on CoolVDS today and lock down your infrastructure properly.