Stop Broadcasting Your Passwords: The Case for SFTP Over SSH
It is 2009. Why are we still having this conversation? I still see logs filled with connection attempts on port 21, and worse, I see developers transferring source code and database dumps over unencrypted channels.
Let me be blunt: Standard FTP is a security suicide mission.
If you are managing a server, whether it's for a client in Oslo or a dev team in Kyiv, using plain FTP sends your username and password in cleartext. Anyone with a packet sniffer (like Wireshark or plain old tcpdump) on any node between you and the server can pluck those credentials out of the air. I have seen it happen. I have cleaned up the defacements that follow.
Today, we are migrating to SFTP (SSH File Transfer Protocol). Not FTPS (FTP over SSL), but SFTP—the subsystem of SSH. It is cleaner, it uses one port, and it is natively supported by the Linux kernel tools we already love.
The Technical Reality: Port 21 vs. Port 22
Standard FTP dates back to 1971. It opens a command channel and a chaotic mess of data channels (Active vs. Passive mode firewall nightmares). It was built for a trusting network, not the hostile internet of 2009.
SFTP runs entirely over the SSH protocol (Port 22). It benefits from the same strong encryption (AES-256) as your shell sessions. If you trust SSH to administer your server, you should trust it to move your files.
Pro Tip: Don't confuse SFTP with "Simple FTP". SFTP stands for SSH File Transfer Protocol. It is a completely different beast designed from the ground up for secure file access.
Configuring a Chrooted SFTP Jail on CentOS 5 / Debian Lenny
The biggest complaint I hear from old-school CTOs is: "But I don't want to give my web designers full shell access just to upload images!"
Until recently, that was a valid pain point. You had to use rshell or messy hacks. But with the recent releases of OpenSSH (4.8p1 and newer), we now have the ChrootDirectory directive native to sshd. This is a game-changer for hosting providers and sysadmins.
Here is how you set up a secure, restricted file transfer user on your CoolVDS instance:
1. Edit your SSH config:
vi /etc/ssh/sshd_config
2. Find the Subsystem line and change it to use the internal-sftp helper (this is crucial for chrooting without copying /bin/bash libraries):
#Subsystem sftp /usr/lib/openssh/sftp-server
Subsystem sftp internal-sftp
3. At the bottom of the file, add your "jail" rules:
Match Group sftponly
ChrootDirectory %h
ForceCommand internal-sftp
AllowTcpForwarding no
X11Forwarding no
4. Create the user and fix permissions (root must own the chroot directory):
groupadd sftponly
useradd -d /var/www/vhosts/client1 -g sftponly client1
chown root:root /var/www/vhosts/client1
chmod 755 /var/www/vhosts/client1
mkdir /var/www/vhosts/client1/public_html
chown client1:sftponly /var/www/vhosts/client1/public_html
Now, when 'client1' logs in via FileZilla or WinSCP, they are locked into their folder. No shell. No snooping around /etc/. Just secure file transfer.
Latency, Throughput, and The TCP Window
Security is primary, but let's talk performance. SFTP creates slightly more CPU overhead due to encryption. On cheap, oversold VPS hosting where the CPU steal time is high, your transfer speeds will crawl. Encryption requires math, and math requires CPU cycles.
This is where hardware selection matters. At CoolVDS, we run on enterprise hardware with dedicated resource allocation. We don't rely on hope; we rely on 15k SAS RAID-10 arrays and the latest Intel Xeon processors.
Furthermore, the SSH protocol is sensitive to latency. If you are in Norway, hosting your data in a US datacenter introduces 100ms+ round-trip times (RTT). Due to the way TCP window scaling works, high latency kills your effective throughput, even on a gigabit line.
By hosting on a VPS in Norway (Oslo), you reduce that latency to single digits (often 2-5ms via NIX). The result? Your SFTP uploads saturate the line instantly. Snappy uploads mean happier developers and faster deployments.
Compliance: The Data Inspectorate is Watching
We operate under Norwegian law. The Personopplysningsloven (Personal Data Act of 2000) mandates that we secure personal data with "adequate technical measures."
If you are transferring customer data containing fødselsnummer or financial records over plain FTP, you are likely in violation of these regulations. The Datatilsynet (Data Inspectorate) does not look kindly on negligence. Moving to SFTP is not just a tech upgrade; it is a compliance necessity.
Comparison: The Old Way vs. The CoolVDS Way
| Feature | Standard FTP | SFTP (SSH) |
|---|---|---|
| Encryption | None (Cleartext) | Strong (AES/Blowfish) |
| Ports Needed | 20, 21 + High Ports (Passive) | 22 (Just one!) |
| Firewall Config | Complex / Nightmare | Simple |
| Vulnerability | Packet Sniffing / MITM | Secure by Design |
Conclusion: Close Port 21 Today
There is no excuse left. Clients like WinSCP and Cyberduck make SFTP usage transparent for Windows and Mac users. The server configuration takes five minutes on a proper Linux distro.
Don't let a lazy config compromise your infrastructure. Packet sniffers are silent; you won't know you've been breached until your root password is sold on a forum.
Need a sandbox to test your new SSH hardening scripts? Deploy a CoolVDS instance in Oslo today. You get full root access, low latency connection to NIX, and the raw CPU power needed to handle encrypted transfers without breaking a sweat.