Stop Broadcasting Your Passwords: The Case for SFTP in 2009
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 where a developer was updating a PHP script from a hotel Wi-Fi connection. A simple packet sniffer running on the same network captured his credentials in plain text. Within ten minutes, their site was injecting malware into visitor browsers.
It is 2009. We have the tools to stop this. Yet, many sysadmins cling to pure FTP or the firewall nightmare that is FTPS (FTP over SSL). The solution is SFTP (SSH File Transfer Protocol). It runs over a single port (22), encrypts everything, and with the release of OpenSSH 4.8p1 and later, we finally have native chrooting capabilities. No more hacking together dummy filesystems just to restrict a user to their home directory.
The Problem with FTPS and Passive Ports
A lot of "Pragmatic" CTOs ask me, "Why not just wrap FTP in SSL?" That works until you try to pass it through a strict firewall. FTPS requires a control channel (port 21) and a random range of passive ports for data transfer. Opening a thousand ports on your firewall just to upload a config.php file is not security; it is a sieve.
SFTP is superior because it rides on the back of the SSH protocol. One port. Strong encryption. Complete session integrity.
Implementing Native SFTP Chroot (The Modern Way)
In the bad old days (meaning 2007), jailing a user to their home directory required copying /bin/ls, /lib/libc.so, and a dozen other binaries into a chroot folder. It was messy and broke every time you updated glibc.
On CoolVDS instances running CentOS 5.3 or Debian Lenny, we utilize the newer ChrootDirectory directive found in OpenSSH 5.x. This allows you to lock a client into a specific folder without copying system binaries.
Step 1: Configure sshd_config
Open /etc/ssh/sshd_config. We are going to tell SSH that any user belonging to the group sftponly must be forced into SFTP mode and locked in their directory.
Subsystem sftp internal-sftp
Match Group sftponly
ChrootDirectory %h
ForceCommand internal-sftp
AllowTcpForwarding no
X11Forwarding no
Note the use of internal-sftp. This is critical. It eliminates the need for a shell binary inside the jail.
Step 2: Permissions Architecture
Here is where most people fail. For ChrootDirectory to work, the directory path up to the root must be owned by root and not writable by any other user or group. If you get a "broken pipe" error in FileZilla, your permissions are wrong.
# Create the group
groupadd sftponly
# Create the user
useradd -d /home/clientsite -g sftponly -s /bin/false webdev
passwd webdev
# Fix permissions (The Critical Part)
chown root:root /home/clientsite
chmod 755 /home/clientsite
# Create a writable upload folder inside
mkdir /home/clientsite/public_html
chown webdev:sftponly /home/clientsite/public_html
Now, when the user logs in via WinSCP or Cyberduck, they see / which is actually /home/clientsite on your server. They cannot wander into /etc to read your configs.
Pro Tip: Do not rely on obscurity. Moving SSH to port 2222 stops script kiddies, but it won't stop a port scan. Use iptables or tools like Fail2Ban to blacklist IPs with too many failed auth attempts. Our CoolVDS templates come with basic iptables rulesets pre-configured to drop invalid packets.
Compliance and the "Datatilsynet" Factor
Operating in Norway means adhering to the Personopplysningsloven (Personal Data Act). While we don't have the strict data fortress laws of some future utopia, the Norwegian Data Inspectorate (Datatilsynet) takes a dim view of unencrypted transfer of personal data. If you are hosting customer data on a VPS in Norway, you have a legal obligation to secure that transport layer. SFTP covers this requirement by default.
Why Infrastructure Matters
Encryption adds CPU overhead. On a cheap, oversold VPS where the host node is thrashing under a load of 500 containers, your SFTP transfer speeds will tank because the CPU is busy fighting for cycles.
This is why we built CoolVDS on enterprise-grade hardware with hardware RAID-10 SAS arrays. We use Xen virtualization to ensure strict memory and CPU isolation. When you negotiate the SSH handshake, you have the dedicated cycles to decrypt the stream instantly, ensuring low latency—even if you are pushing code from a remote office in Kyiv back to our datacenter in Oslo.
The Verdict
FTP is a relic of the 90s. There is no excuse for using it in a production environment today. It exposes your credentials, fails compliance audits, and complicates firewall configurations.
Switch to SFTP. It is built into the Linux fabric, it is secure, and with the new OpenSSH configs, it is finally easy to manage. If you need a sandbox to test your chroot configurations without risking your main production box, spin up a CoolVDS instance. We offer clean, unbloated CentOS and Debian installs that are ready for serious work in under 60 seconds.