Stop Broadcasting Passwords: The Definitive Guide to Hardening File Transfers with SFTP

If you are still running a standard FTP daemon on port 21 in 2011, you might as well print your root credentials on a billboard in the middle of Karl Johans gate. It is harsh, but it is true.

I recently audited a media agency in Oslo that complained about ‘mysterious file modifications’ on their web servers. The culprit wasn't a zero-day exploit or a complex SQL injection. It was a developer logging into an FTP server from an unsecured hotel Wi-Fi. A packet sniffer running on the same network captured the USER and PASS commands in cleartext. Game over.

As systems administrators, we have a responsibility to kill legacy protocols that compromise infrastructure. With the increasing scrutiny from Datatilsynet regarding the Personal Data Act (Personopplysningsloven), protecting data in transit is not optional. It is mandatory.

The Anatomy of Failure: Why FTP Must Die

File Transfer Protocol (FTP) was designed in an era where the internet was a trusting network of academic institutions. It offers zero encryption. When you authenticate, the server and client shout at each other without a whisper.

Here is what a script kiddie sees when you use standard FTP. I ran tcpdump on a gateway while a client connected:

# tcpdump -A -i eth0 port 21
... 
USER admin
PASS SecretPass123
...

That is your server key, floating in the ether. The solution is SFTP (SSH File Transfer Protocol). Unlike FTPS (FTP over SSL), which requires messy passive port ranges and firewall holes, SFTP runs entirely over the SSH protocol (port 22 by default). It is firewall-friendly, encrypted by default, and leverages the rock-solid OpenSSH daemon.

Implementing Chrooted SFTP on CentOS 5 / 6

The challenge with SFTP historically was restricting users. You wanted them to upload files, not browse /etc/shadow via an SSH shell. Since OpenSSH 4.8, the internal-sftp subsystem allows us to chroot users easily without setting up complex /dev nodes and library copies.

We use this exact configuration on CoolVDS managed instances to ensure tenant isolation. Here is the battle-tested configuration for a secured environment.

1. Configure OpenSSH

Edit your /etc/ssh/sshd_config file. We need to replace the external sftp-server with the internal subsystem.

# /etc/ssh/sshd_config

# Comment out the default subsystem
# Subsystem sftp /usr/lib/openssh/sftp-server

# Use the internal subsystem
Subsystem sftp internal-sftp

# Match a specific group to apply restrictions
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 the user. This is where 90% of admins get stuck.

2. Create the Restricted Group and User

We create a group called sftponly and add a user to it. Do not give them a valid shell.

# Create the group
groupadd sftponly

# Create the user with no shell access
useradd -d /home/clientsite -g sftponly -s /bin/false webdev

# Set a strong password
passwd webdev

3. Fix Permissions ( The Critical Step)

OpenSSH requires the chroot root directory to be owned by root with 755 permissions. The user cannot write to the chroot root; they must write to a subdirectory inside it.

# Secure the home directory
chown root:root /home/clientsite
chmod 755 /home/clientsite

# Create the writable content directory
mkdir /home/clientsite/public_html
chown webdev:sftponly /home/clientsite/public_html
chmod 755 /home/clientsite/public_html

4. Reload and Verify

Restart the SSH service. On Red Hat/CentOS systems:

service sshd restart

Now, attempt to connect via terminal:

$ sftp webdev@your-server-ip
Connecting to your-server-ip...
webdev@your-server-ip's password: 
sftp> pwd
Remote working directory: /
sftp> cd /etc
Couldn't canonicalise: No such file or directory

Perfect. The user sees their home directory as the system root (/) and cannot escape. They can only write inside public_html.

Latency and The Handshake

Security comes with a cost: CPU cycles. The initial SSH handshake involves asymmetric encryption (RSA/DSA) and the exchange of session keys. On an overloaded server with high I/O wait (common on oversold budget VPS providers), this handshake can take 3-5 seconds. For a developer pushing hundreds of small PHP files, that lag is excruciating.

This is where infrastructure quality matters. At CoolVDS, we run KVM virtualization on enterprise-grade hardware. We don't use noisy containers that share kernel resources aggressively. Our servers in Oslo typically deliver sub-10ms latency to Nordic ISPs.

When you are performing an encrypted file transfer, the bottleneck often shifts from network bandwidth to disk I/O (random writes for thousands of small files) and CPU (encryption overhead). By utilizing high-performance SSD storage (still a rarity in the VPS market) and dedicated CPU allocation, we ensure that sftp feels as snappy as cp.

Final Thoughts

Moving to SFTP is not just a technical upgrade; it is a compliance necessity for any Norwegian business handling customer data. You eliminate a vector of attack and simplify your firewall rules simultaneously.

Do not let legacy protocols compromise your uptime or your reputation. If you need a sandbox to test these configurations without risking your production environment, spin up a CoolVDS instance. You get root access, a clean IP, and the raw performance needed to handle encrypted traffic without a sweat.

Secure your workflow. Switch to SFTP.