Stop Broadcasting Your Root Password
If you are still running a standard FTP daemon like proftpd or vsftpd without strict TLS encapsulation, you might as well print your root password on a billboard in downtown Oslo. I recently audited a client's legacy infrastructure hosted on a budget provider. A simple tcpdump on the gateway revealed their developers were pushing code via standard FTP. We captured three admin credentials in less than ten minutes.
It is 2010. The internet is not a friendly place. With packet sniffers becoming standard tools for script kiddies and the Norwegian Data Protection Authority (Datatilsynet) tightening the screws on how we handle personal data under the Personal Data Act, you have no excuse for cleartext protocols.
Many sysadmins hesitate to move to SFTP (SSH File Transfer Protocol) because they believe it's difficult to restrict users to specific directories. That used to be true. But with recent updates to OpenSSH, native chrooting is reliable and ready for production.
The Problem with FTP (and FTPS)
Standard FTP was designed in an era where the internet was a university experiment. It opens random high-numbered ports for data transfer, which makes configuring iptables or hardware firewalls a nightmare. You end up opening wide port ranges, increasing your attack surface.
FTPS (FTP over SSL) fixes the encryption issue but compounds the firewall headache. It breaks Network Address Translation (NAT) frequently because the encrypted control channel hides the port negotiation from the firewall.
The Solution: SFTP via OpenSSH
SFTP is not FTP. It is a file transfer extension of the SSH protocol. It uses a single port (TCP 22), is fully encrypted, and packet inspection is impossible. The only downside used to be that giving a user SFTP access also gave them shell access. We don't want web developers poking around /etc/.
However, OpenSSH versions 4.9 and later (standard in CentOS 5.4 and Debian Lenny) introduced the internal-sftp subsystem and Match blocks. This allows us to lock users into a specific folder without needing complex patch sets or third-party shells like rssh.
Configuration: The "Jail" Setup
Here is the configuration we use on CoolVDS production images to secure client data. This assumes you are running a standard CentOS 5 or Debian 5 environment.
1. Edit the SSH Daemon Config
Open /etc/ssh/sshd_config. Find the line describing the Subsystem (usually near the bottom) and change it to use the internal process:
#Subsystem sftp /usr/lib/openssh/sftp-server
Subsystem sftp internal-sftp2. Create the Restricted Group
We don't want to apply this to root, only to specific file-transfer accounts.
groupadd sftponly3. Configure the Match Block
At the very end of your sshd_config, add these lines. This tells SSH: "If the user is in the 'sftponly' group, force them into their home directory and deny shell access."
Match Group sftponly
ChrootDirectory %h
ForceCommand internal-sftp
AllowTcpForwarding no4. Permissions (The Tricky Part)
This is where 90% of admins fail. For ChrootDirectory to work, the directory owned by root must not be writable by the user. If the permissions are wrong, the connection will drop instantly.
# Create user
useradd -d /home/clientsite -g sftponly clientuser
passwd clientuser
# Fix permissions for Chroot
chown root:root /home/clientsite
chmod 755 /home/clientsite
# Create a writable folder INSIDE the jail
mkdir /home/clientsite/public_html
chown clientuser:sftponly /home/clientsite/public_htmlNow, when clientuser logs in via WinSCP or FileZilla, they are locked in /home/clientsite and can only upload files to public_html.
Performance Considerations
Some argue that SFTP is slower than FTP due to encryption overhead. On an overloaded shared host, this might be true. SSH requires CPU cycles to encrypt traffic (AES-128 or AES-256).
This is where your choice of infrastructure matters. At CoolVDS, we don't oversell our CPU cores. We use KVM virtualization which gives you dedicated access to the processor instructions. Combined with our low-latency connections to the NIX (Norwegian Internet Exchange), the encryption overhead is negligible. You get security without the lag.
Pro Tip: If you are transferring massive files (gigabytes of log data) securely between servers, standardscpis faster, butrsync -avz -e sshis smarter because it handles resume and compression.
Conclusion
Compliance with Norwegian privacy standards isn't just about paperwork; it's about technical implementation. Moving from FTP to SFTP is a low-hanging fruit that significantly hardens your server against interception attacks.
Don't risk your client's data on legacy protocols. Spin up a CoolVDS instance today—our default templates are optimized for modern OpenSSH configurations, giving you a secure foundation from the first boot.