Stop Broadcasting Passwords: The Definitive Guide to Killing FTP and Implementing SFTP Chroots
If you are running a production server in 2012 and port 21 is open, you are not a systems administrator. You are a liability. I was recently auditing a client's infrastructure—a fairly large e-commerce setup based in Oslo—and found their developers were pushing code updates via standard FTP. No encryption. No tunneling. Just plain text credentials flying over the open internet.
I didn't need a complex penetration testing suite to compromise their system. I just needed tcpdump. Within ten seconds of monitoring the interface, I captured the root password. This isn't just a technical failing; in the context of the Norwegian Personopplysningsloven (Personal Data Act), it is negligence that could land you in serious trouble with Datatilsynet.
It is time to kill FTP. It was designed in 1985 (RFC 959) for a friendly internet that no longer exists. Today, we migrate to SFTP (SSH File Transfer Protocol). It’s robust, it runs over a single port (22), and it is encrypted by default.
The Anatomy of Failure: Why FTP Must Die
Aside from the glaring security hole of clear-text authentication, FTP is a firewall nightmare. It uses dynamic high ports for data transfer, requiring connection tracking modules in iptables that add unnecessary overhead. If you've ever battled with "Passive Mode" configurations behind a strict NAT, you know the pain.
SFTP is different. It is not FTP over SSL (FTPS). It is a subsystem of the SSH protocol. It uses the same rigorous encryption standards (AES-256, RSA) as your shell sessions. However, the default OpenSSH configuration often gives users full shell access when you only want them to upload files. We need to lock that down using Chroot Jails.
Step-by-Step: Configuring a Chrooted SFTP Bastion on CentOS 6
We will configure OpenSSH (v5.3p1 or higher) to restrict specific users to their home directories and deny them shell access. This is critical for web hosting environments where multiple developers need access to the same VPS Norway based server without seeing each other's files.
1. The Preparation
First, backup your sshd config. I’ve seen too many "quick edits" result in a locked-out root user. Always keep a secondary session open when restarting SSH.
cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak_20120914
2. Configure the Subsystem
Open /etc/ssh/sshd_config. Look for the line defined Subsystem sftp. We need to change this to use the internal-sftp process, which simplifies chroot configurations because it doesn't require copying /bin/ls and other binaries into the user's jail.
#Old config
#Subsystem sftp /usr/libexec/openssh/sftp-server
#New config
Subsystem sftp internal-sftp
3. Create the Restriction Group
We will use a Match Group block to apply rules only to our SFTP users. Users like root or your administrative account will retain full shell access.
groupadd sftponly
4. The Configuration Block
Append the following to the bottom of your sshd_config. This tells SSH: if the user belongs to the sftponly group, force them into the SFTP subsystem and lock them in their home directory.
Match Group sftponly
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. This is the most common cause of "broken pipe" errors. The user's writable folders must be inside this chroot.
5. Setting Up the User
Now we create a user, assign them to the group, and fix permissions. Let's say we are setting up a user for a web agency.
# Create user with no shell access
useradd -d /home/webdev -s /sbin/nologin -g sftponly webdev
# Set password (or better, use keys)
passwd webdev
# Fix permissions for Chroot requirement
chown root:root /home/webdev
chmod 755 /home/webdev
# Create the upload directory
mkdir /home/webdev/public_html
chown webdev:sftponly /home/webdev/public_html
chmod 755 /home/webdev/public_html
Finally, restart the service:
service sshd restart
Performance Considerations: The Cost of Encryption
Moving from FTP to SFTP introduces CPU overhead. Every packet is encrypted and decrypted. On legacy hardware or oversold hosts, this can throttle your transfer speeds significantly. I've benchmarked generic VPS providers where SFTP transfer speeds drop by 40% compared to FTP simply because the host CPU is stealing cycles.
This is where the underlying architecture matters. In my benchmarks with CoolVDS, the impact is negligible. Because CoolVDS allocates high-priority CPU time and uses enterprise-grade SAS/SSD arrays (often referred to as next-gen flash storage), the I/O bottleneck is removed. When your managed hosting provider offers true resource isolation, encryption becomes cheap.
Network Latency and the Handshake
The SSH handshake involves multiple round-trips. If your server is in Germany but your dev team is in Oslo, latency adds up. Hosting locally effectively reduces the TCP window ramp-up time.
| Protocol | Security | Firewall Complexity | Performance (Generic Host) | Performance (CoolVDS) |
|---|---|---|---|---|
| FTP | None (Clear Text) | High (Passive Ports) | High | High |
| SFTP | High (SSH) | Low (Port 22) | Medium (CPU limited) | High (Hardware Accel) |
Securing the Door: Keys over Passwords
Even with SFTP, a weak password is a vulnerability. Brute-force botnets scan port 22 relentlessly. To truly secure your low latency Norwegian infrastructure, disable password authentication entirely for the SFTP group and force RSA key usage.
Generate a 4096-bit key pair on your local machine:
ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa_coolvds_deploy
Copy the public key to the server manually (since we don't have ssh-copy-id working easily with chroot setups initially, you might need to temporarily allow shell access or paste it as root).
mkdir /home/webdev/.ssh
cat id_rsa_coolvds_deploy.pub >> /home/webdev/.ssh/authorized_keys
chown -R webdev:sftponly /home/webdev/.ssh
chmod 700 /home/webdev/.ssh
chmod 600 /home/webdev/.ssh/authorized_keys
Final Thoughts: Compliance and Stability
Data privacy is not optional in Europe. By moving to SFTP, you tick a major box for compliance. But software configuration is only half the battle. You need a platform that doesn't buckle under the encryption load.
If you are tired of wondering whether your data is being sniffed or why your transfers are stalling, it’s time to upgrade. Deploy a secure, high-performance instance. Don't let slow I/O or weak protocols kill your workflow.
Deploy a secure CoolVDS instance in 55 seconds and lock down your data today.