FTP is Dead: Securing Your Norwegian Infrastructure with SFTP Chroots

If you are still running a standard FTP daemon listening on port 21 in 2012, you are not just risking your data; you are practically inviting attackers to take it. I recently audited a client's legacy infrastructure hosted in a budget datacenter outside Oslo. They were baffled as to how their config.php files were being injected with malware repeatedly. The culprit wasn't a zero-day exploit or a complex SQL injection. It was a developer updating the site from a hotel Wi-Fi using plain FTP.

Packet sniffers like Wireshark make capturing FTP credentials trivial. It takes seconds. Once they have the credentials, they have the keys to your kingdom. In the context of Norwegian privacy laws and the strict guidelines from Datatilsynet, failing to encrypt file transfers containing personal data isn't just bad practice; it's a liability.

It is time to kill FTP. The industry standard replacement is SFTP (SSH File Transfer Protocol). It runs over the SSH protocol, encrypting both commands and data. However, giving every file uploader full SSH shell access is dangerous. The solution? Chrooted SFTP.

The Architecture of a Secure Chroot

Many system administrators hesitate to move to SFTP because they believe it requires giving users shell access (/bin/bash). This is incorrect. Using OpenSSH's internal-sftp subsystem, we can lock users into a specific directory, deny them shell access, and force all traffic over an encrypted channel.

This setup is particularly vital if you are hosting multiple clients on a single CoolVDS instance. Our KVM-based virtualization ensures kernel isolation between tenants, but you must ensure user isolation within your own OS.

Step 1: Configure OpenSSH

First, backup your current configuration. We are going to modify /etc/ssh/sshd_config. Open it with your preferred editor (vi or nano) and look for the Subsystem line.

# Old default
# Subsystem sftp /usr/lib/openssh/sftp-server

# Change to internal-sftp to allow chrooting without extra libraries
Subsystem sftp internal-sftp

At the bottom of the file, we add a Match Group block. This tells SSH: "If a user belongs to the group sftponly, apply these specific rules."

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

Pro Tip: The ChrootDirectory %h directive tells SSH to lock the user inside their home directory. However, for this to work, the directory permissions must be owned by root and not writable by any other user. This is the most common point of failure for new admins.

Step 2: Create the Group and User

Now, let's create the isolation group and a test user. I'll use standard RHEL/CentOS 6 commands, but these work on Debian 6 (Squeeze) as well.

# Create the group
groupadd sftponly

# Create a user with no shell access
useradd -g sftponly -s /bin/false -d /home/client_site johndoe

# Set the password
passwd johndoe

Step 3: Fix Permissions (The Critical Part)

As mentioned, the chroot root must be owned by root. Inside that, we create a writable folder for the user.

# Set ownership of the home directory to root
chown root:root /home/client_site
chmod 755 /home/client_site

# Create the actual content directory (e.g., public_html)
mkdir /home/client_site/public_html

# Give the user ownership of the inner directory
chown johndoe:sftponly /home/client_site/public_html

Now, when johndoe logs in via SFTP, they will land in / (which is actually /home/client_site) and see public_html. They cannot navigate up to /etc or see other users' data.

Step 4: Restart and Verify

service sshd restart

Test the connection from another machine:

sftp johndoe@your-coolvds-ip

Performance Considerations: Encryption Overhead

One concern I hear from the "Performance Obsessive" crowd is that encryption adds latency. In 2012, with the prevalence of Sandy Bridge Xeons supporting AES-NI instructions, this overhead is negligible for file transfers.

What matters more is disk I/O. If you are serving static assets via SFTP uploads, you need storage that can handle random write operations without locking. This is why CoolVDS utilizes enterprise-grade SSD storage arrays (RAID 10) rather than standard mechanical SAS drives. When you are pushing thousands of small PHP files, the IOPS (Input/Output Operations Per Second) of SSDs significantly reduces the time to "live", regardless of the encryption protocol.

Why Local Hosting Matters

For Norwegian businesses, latency to the server is critical for developer experience. Using a US-based host adds 100ms+ to every packet exchange. Due to the chatty nature of SFTP (it waits for acknowledgement packets), high latency kills transfer speeds.

Hosting on CoolVDS nodes in Oslo connects you directly to the NIX (Norwegian Internet Exchange). We see ping times as low as 2-5ms from major Norwegian ISPs like Telenor and Altibox. This makes SFTP feel as snappy as a local copy command.

Final Thoughts

Security is not a product; it is a process. Moving from FTP to SFTP is the first step in hardening your server against the most common reconnaissance attacks. Don't wait for a data breach to explain to Datatilsynet why you were using a protocol from 1985.

Ready to lock down your infrastructure? Spin up a CoolVDS SSD instance today. Our default templates come with OpenSSH pre-installed and optimized for low-latency connections across Northern Europe.