Console Login
Home / Blog / Security & Compliance / FTP is Dead: Securing Your Data Transfer with SFTP and OpenSSH
Security & Compliance 9 views

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.

/// TAGS

/// RELATED POSTS

Automating Server Hardening: A CTO’s Guide to Surviving Datatilsynet without Ulcers

Manual security checklists are a liability. Learn how to automate compliance using Ansible and OpenS...

Read More →

The Perimeter is Dead: Architecting 'Zero Trust' Security on Linux in 2015

The 'Castle and Moat' security strategy is failing. Learn how to implement a Zero Trust architecture...

Read More →

Automating Compliance: How to harden your Norwegian VPS without losing your mind

Manual security audits are a liability in 2015. Learn how to use Ansible and KVM isolation to satisf...

Read More →

Hardening the Stack: Defending Norwegian Web Apps Against the OWASP Top 10 (2012 Edition)

It is 2012, and SQL Injection is still king. A battle-hardened guide to securing LAMP stacks, comply...

Read More →

Paranoia is a Virtue: The 2012 Guide to Linux Server Hardening in Norway

Following the massive security breaches of 2011, default configurations are no longer acceptable. Le...

Read More →

Locking Down Your Linux Box: Essential Server Hardening Survival Guide (2011 Edition)

Stop relying on 'security by obscurity'. A battle-hardened guide to securing your Linux VPS against ...

Read More →
← Back to All Posts