FTP is Dead: Why Smart Sysadmins in Norway are Locking Down Port 21 with SFTP

Let’s be honest with each other. If you are still running a standard FTP daemon listening on port 21 in 2010, you aren't just taking a risk—you are being negligent. I recently audited a client's infrastructure in Oslo who was baffled as to how their e-commerce database was compromised. They had a firewall, they had strong passwords, but their lead developer was updating the site via standard FTP from a hotel Wi-Fi network.

It took me exactly five minutes with tcpdump to show them why their security model was broken. Standard FTP sends everything—including your username and password—in cleartext. In an era where we are seeing a massive rise in packet sniffing attacks and automated botnets targeting standard ports, relying on 1980s protocols is not an option.

For Norwegian businesses, this is doubly critical. The Datatilsynet (Norwegian Data Protection Authority) is cracking down on how personal data is handled under the Personopplysningsloven. If you leak customer data because you were too lazy to configure SSH keys, negligence is the least of your legal worries.

The Anatomy of Failure: Why FTP Must Die

When you connect to an FTP server, the control channel opens on TCP port 21. Here is what that looks like to anyone sitting on the node between you and your server (like an ISP admin or a guy at the cafe):

USER admin
PASS s3cr3tp@ssw0rd
CWD /var/www/html
STOR index.php

That PASS command is visible to the world. It doesn't matter how complex your password is if I can read it off the wire.

The solution is SFTP (SSH File Transfer Protocol). Do not confuse this with FTPS (FTP over SSL), which requires messy certificate management and often breaks through NAT firewalls due to passive port range issues. SFTP runs entirely over the SSH protocol (Port 22). It is encrypted, multiplexed, and if you are using a proper provider like CoolVDS, it is already supported by the underlying architecture.

Implementation: Configuring Chrooted SFTP on CentOS 5 / Debian Lenny

One of the biggest complaints I hear from hosting providers is: "I don't want to give my web developers full shell access just to upload files."

This was a valid complaint until recently. However, modern versions of OpenSSH (starting with 4.8p1) introduced the ChrootDirectory directive. This allows us to lock a user into a specific folder without giving them a full shell environment. This is the "Gold Standard" setup we use on all managed CoolVDS instances.

Step 1: The Server Configuration

Open your ssh config file. On most systems, this is located at /etc/ssh/sshd_config.

# vi /etc/ssh/sshd_config

You need to comment out the default sftp subsystem and replace it with the internal-sftp wrapper. This is critical for chrooting because it avoids the need to copy binary libraries (like /bin/bash or /lib/libc.so.6) into the user's jail.

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

Step 2: Defining the Match Block

At the very bottom of your configuration file, we add a rule that matches a specific group of users. Let's call this group sftponly. Anyone in this group will be forced into their home directory and denied X11 forwarding or TCP tunneling.

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

Restart the SSH service to apply changes:

# /etc/init.d/ssh restart  # On Debian/Ubuntu
# service sshd restart     # On CentOS/RHEL

Step 3: Creating the User and Permissions

This is where most admins get stuck. For the ChrootDirectory to work, root must own the chroot directory, and it must not be writable by anyone else. This is a strict security requirement of OpenSSH.

# groupadd sftponly
# useradd -d /var/www/clients/client1 -g sftponly -s /bin/false webdev1
# passwd webdev1

Now, set the ownership. The user cannot own their own root folder, so we usually create an html or public_html folder inside for them to write to.

# chown root:root /var/www/clients/client1
# chmod 755 /var/www/clients/client1

# mkdir /var/www/clients/client1/public_html
# chown webdev1:sftponly /var/www/clients/client1/public_html
# chmod 755 /var/www/clients/client1/public_html

Pro Tip: If you see "Connection closed" immediately upon trying to login, check /var/log/auth.log or /var/log/secure. 99% of the time, it is because the directory permissions on the chroot path are wrong. OpenSSH is ruthless about permissions.

Latency, encryption, and the "Slow" Myth

A common myth floating around forums is that SFTP is slower than FTP because of the encryption overhead. In 2002, on a Pentium III, maybe. Today, on modern Xeon processors, the overhead is negligible.

However, latency does matter. The SSH protocol is "chatty"—it requires acknowledgments for data packets. If your server is in the US and you are in Norway, the speed of light becomes your bottleneck. This is why hosting geographically close to your user base is critical.

For our Norwegian clients, we deploy servers directly connected to NIX (Norwegian Internet Exchange). When your Round Trip Time (RTT) is 2ms instead of 150ms, SFTP file transfers feel instantaneous. High latency kills throughput on encrypted streams faster than CPU limits ever will.

Why Your Hosting Architecture Matters

Implementing this security requires root access. You cannot configure sshd_config on a cheap $3 shared hosting plan. You are at the mercy of the host's generic settings.

This is where Virtual Private Servers (VPS) become mandatory for professional work. With CoolVDS, we provide KVM-based virtualization. Unlike OpenVZ containers where kernel settings are shared and often restricted, KVM gives you a dedicated kernel. You can modify your SSH daemons, compile custom kernels, or even set up complex IPTables firewall rules to rate-limit SSH connection attempts (preventing brute force attacks).

Automating Backups with Keys

Once you have moved to SFTP/SSH, you unlock the power of automation. You can stop using manual FTP clients like FileZilla and start using rsync for differential backups. This script snippet only transfers the parts of files that have changed, saving massive bandwidth:

#!/bin/bash
# Backup script utilizing SSH keys
rsync -avz -e "ssh -p 22" /local/project/ user@coolvds-host:/var/www/html/

Try doing that with standard FTP.

Conclusion

The days of plain text protocols are over. Between the growing sophistication of sniffing tools and the strict requirements of Norwegian privacy laws, running Port 21 is a liability you cannot afford.

Switching to SFTP is not just about security; it is about workflow efficiency and professional standards. It requires a server environment that gives you the control to configure it correctly. Do not let outdated protocols or restrictive shared hosting compromise your infrastructure.

Ready to lock down your infrastructure? Deploy a KVM instance with full root access on CoolVDS today and get the low-latency performance your Norwegian clients expect.