Stop Broadcasting Your Passwords to the Entire Subnet

It is 2011. If you are still using standard FTP (File Transfer Protocol) on port 21 to manage your production 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 legacy shared metal—and found their developers FTPing code updates from open coffee shop Wi-Fi networks.

A simple run of tcpdump or Wireshark on that network would reveal every single credential in cleartext. In an era where packet sniffing is trivial, relying on FTP is professional negligence. With the strict enforcement of the Personal Data Act (Personopplysningsloven) here in Norway, a breach caused by such basic negligence could land you in hot water with Datatilsynet.

There is no excuse. The tools to fix this have been in OpenSSH for years. Today, we are killing FTP and moving to SFTP (SSH File Transfer Protocol).

The Difference: FTPS vs. SFTP

Do not confuse the two. FTPS is FTP over SSL/TLS. It's a pain to firewall because it requires opening a passive port range (often 1000+ ports). SFTP, on the other hand, is a subsystem of SSH. It runs over a single port (usually 22). It is cleaner, encrypts everything (commands and data), and is native to Linux.

The Implementation: Chrooting SFTP Users

The main argument I hear against SFTP is: "But I don't want my web developers to have shell access!"

Valid point. You don't want a frontend designer poking around /etc/. The solution is the internal-sftp subsystem introduced in newer OpenSSH versions. It allows you to chroot users to their home directories without giving them a shell.

Here is how we configure this on a standard CoolVDS instance running CentOS 5.6 or Debian 6 (Squeeze).

1. Configure sshd_config

Open your SSH config. If you are on a CoolVDS server, you have full root access, so fire up Vim:

Find the Subsystem line. Comment out the default and add the internal subsystem:

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

Next, add a block at the very end of the file to handle your restricted users. We will match based on a group named filetransfer:

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

Pro Tip: The ChrootDirectory must be owned by root and not writable by any other user or group. If permissions are wrong, the user will be kicked out immediately upon login. The hierarchy should look like /home/user/uploads, where /home/user is owned by root, and uploads is owned by the user.

2. Create the User and Group

Now, let's lock down a new user.

Fix the permissions for the chroot jail:

3. Restart SSH

Do not lock yourself out. Always verify config syntax before restarting.

Why Infrastructure Matters

Implementing security protocols adds slight overhead. Encryption requires CPU cycles. On bargain-bin hosting with oversold CPUs, switching to SFTP for large file transfers can actually throttle your speeds.

This is why hardware selection is critical. At CoolVDS, we use Xen virtualization to ensure strict resource isolation. Unlike OpenVZ containers where a neighbor's heavy encryption load can steal your CPU time, our Xen instances guarantee your cycles are yours. Whether you are pushing git repositories or large media assets via SFTP, the latency stays low—especially if you are peering through NIX (Norwegian Internet Exchange) in Oslo.

Client-Side Tools

You don't need fancy software to connect. Standard tools work out of the box:

• FileZilla: Just change the protocol to "SFTP - SSH File Transfer Protocol" and port to 22.
• WinSCP: The standard for Windows users.
• Terminal: sftp webdev01@your-server-ip

Final Thoughts

Security is not about convenience; it is about survival. In 2011, with the increasing sophistication of automated bots and script kiddies scanning European IP ranges, leaving port 21 open is asking for trouble.

If you are serious about data integrity and low latency, you need a VPS that supports your security posture rather than fighting it. Don't let slow I/O or oversold nodes compromise your encryption performance.

Ready to lock down your infrastructure? Spin up a CoolVDS instance with SSD-cached storage today and get full root control in under 60 seconds.