Console Login

FTP is Dead: Securing Your Data Transfer with SFTP and OpenSSH

Stop Broadcasting Your Passwords to the World

It is 2011. If you are still using standard FTP (File Transfer Protocol) to manage your server, 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 a legacy shared platform. I ran a simple tcpdump on their gateway while their developer uploaded a patch.

Result? I captured their database credentials in cleartext within 14 seconds. Standard FTP sends everything unencrypted. In an era where open Wi-Fi is becoming standard at coffee shops and conferences, this is unacceptable.

For serious system administrators, the only path forward is SFTP (SSH File Transfer Protocol). Unlike FTPS (FTP over SSL), which requires a nightmare of firewall ports for the control and data channels, SFTP rides entirely over the SSH protocol (Port 22). It is cleaner, safer, and with the right configuration, you can lock users into their home directories just as tightly as old-school FTP daemons.

The Compliance Reality: Datatilsynet is Watching

Here in Norway, the Personopplysningsloven (Personal Data Act) mandates that we secure sensitive data with appropriate measures. While the Data Protection Directive (95/46/EC) gives us the framework, Datatilsynet enforces the reality. If you leak customer data because you were using a protocol from 1985, "I didn't know" is not a valid legal defense.

Moving to SFTP isn't just about avoiding hackers; it's about due diligence. Your hosting environment needs to demonstrate that you take security seriously.

Configuration: Chrooting SFTP in OpenSSH

Many admins hesitate to switch because they think giving a user SFTP access means giving them a full shell. This used to be true, but modern versions of OpenSSH (4.8+) introduced the ChrootDirectory directive. This allows us to restrict a user to a specific folder without giving them command-line access.

Here is the battle-tested configuration we use on CoolVDS instances running CentOS 6 or Debian Squeeze. This setup creates a jail that prevents users from browsing the entire filesystem.

1. Create the Group and User

groupadd sftponly
useradd -g sftponly -s /bin/false -d /home/client_site client_user
passwd client_user

Note the /bin/false shell. This ensures they cannot login via a terminal session.

2. Configure sshd_config

Open /etc/ssh/sshd_config. Comment out the default Subsystem line and add the internal-sftp configuration. The internal-sftp mechanism is crucial because it does not require support files inside the chroot jail.

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

Match Group sftponly
    ChrootDirectory %h
    ForceCommand internal-sftp
    AllowTcpForwarding no
    X11Forwarding no
Pro Tip: The directory specified in ChrootDirectory (in this case %h, the home directory) must be owned by root and not writable by any other user. If permissions are wrong, the connection will drop immediately. Create a subfolder like /home/client_site/www for the actual uploads.

3. Restart SSH

service sshd restart

Performance: The Encryption Tax

One argument I hear from the "old guard" is that encryption adds latency. Years ago, on Pentium 4 hardware, this might have been a discussion. Today, it is irrelevant.

SFTP encrypts the data stream, which does require CPU cycles. However, on modern architecture—like the Intel Xeon processors we deploy across the CoolVDS fleet—the overhead is negligible. We utilize hardware-accelerated AES instruction sets where possible. The bottleneck is rarely the CPU; it is the disk I/O.

This is where infrastructure choice matters. While many VPS providers in the Nordic region are still spinning old SATA drives in RAID 5, CoolVDS utilizes high-performance RAID-10 SAS and enterprise-grade SSD caching. When you are transferring thousands of small PHP files over an encrypted tunnel, that random I/O performance prevents your session from hanging.

The Verdict

FTP is a relic. It belongs in a museum, not on a production server. By switching to SFTP, you gain:

  • Single Port Security: Only Port 22 needs to be open.
  • Full Encryption: No more cleartext passwords.
  • Compliance: Alignment with Norwegian security standards.

If you are managing sensitive data, you need a host that gives you the root access required to configure these rigorous security policies. Don't settle for restrictive shared hosting panels.

Need a sandbox to test your SSH hardening? Deploy a CentOS 6 instance on CoolVDS today and experience the stability of true enterprise virtualization.