Stop Broadcasting Your Root Password: The Case for SFTP

It is 2011. We are seeing a massive shift in how automated botnets scan for vulnerabilities, yet I still see senior administrators opening port 21 on production servers. If you are still using standard FTP (File Transfer Protocol) to manage your web server, you might as well print your root password on a billboard in downtown Oslo.

The problem is fundamental: FTP transmits everything in cleartext. Including your username. Including your password. Anyone on the same Wi-Fi network with a copy of Wireshark or `tcpdump` can sniff your credentials in milliseconds. In a corporate environment, this is negligence. In the context of the Norwegian Personopplysningsloven (Personal Data Act), it is a compliance nightmare waiting to happen.

The Alternative: SFTP (SSH File Transfer Protocol)

Many confuse SFTP with FTPS. They are not the same.

• FTPS is FTP over SSL. It requires an SSL certificate and, more annoyingly, it requires opening a wide range of passive ports in your firewall (`iptables`). This is a pain to manage with NAT.
• SFTP is a subsystem of the SSH protocol. It runs over the standard port 22. It is encrypted by default. It requires no extra holes in your firewall.

For a Battle-Hardened DevOps professional, SFTP is the only logical choice. It piggybacks on the existing trust relationship of your SSH keys and offers full file system manipulation without the overhead of maintaining a separate FTP daemon like `vsftpd` or `proftpd`.

Configuring a Chrooted SFTP Jail on CentOS 6

One valid concern is restricting users. You don't want a web developer snooping around `/etc/` just because they need to upload a PHP file. The solution is the ChrootDirectory directive available in newer versions of OpenSSH (4.9+), which comes standard on our CoolVDS CentOS 6 images.

Here is how to lock a user down to a specific directory while allowing secure file transfer.

1. Edit your SSH Configuration

Open /etc/ssh/sshd_config with your editor of choice (vi/vim):

Find the Subsystem line and modify it to use the internal-sftp handler. This is crucial for chrooting because it does not require /bin/sh or other libraries inside the jail.

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

Next, add the matching rules at the bottom of the file to trap the specific group:

Match Group sftponly
    ChrootDirectory %h
    ForceCommand internal-sftp
    AllowTcpForwarding no
    X11Forwarding no

2. Create the User and Group

Now we create the group and a user, ensuring they cannot log in via a standard shell.

# groupadd sftponly
# useradd -d /var/www/vhosts/client1 -g sftponly -s /sbin/nologin client1
# passwd client1

3. Permissions: The Tricky Part

For Chroot to work, the directory owned by root must not be writable by anyone else. This is where most people get "Broken Pipe" errors.

# chown root:root /var/www/vhosts/client1
# chmod 755 /var/www/vhosts/client1
# mkdir /var/www/vhosts/client1/public_html
# chown client1:sftponly /var/www/vhosts/client1/public_html

Now, the user `client1` can SFTP into the server, but they will be locked inside their home directory and can only write to `public_html`. Perfect for handing off access to freelancers without compromising the kernel.

Pro Tip: Always use SSH Keys instead of passwords, even for SFTP users. It prevents brute-force attacks which are rampant on port 22. You can place the public key in /var/www/vhosts/client1/.ssh/authorized_keys just like a normal user.

Hardware Implications: The Encryption Overhead

Moving from plain text to full encryption adds CPU overhead. Every packet transferred via SFTP must be encrypted and decrypted. On legacy shared hosting environments where hundreds of users fight for a single core, this throttles transfer speeds significantly.

This is where architecture matters. At CoolVDS, we don't oversell our CPU cycles. We utilize KVM (Kernel-based Virtual Machine) virtualization which provides better isolation and direct access to CPU instructions compared to older container technologies like Virtuozzo. When you are pushing gigabytes of data to your Norwegian servers, you need that raw processing power to handle the SSH encryption stream without latency spikes.

Compliance and The Norwegian Data Inspectorate

If you are hosting data for Norwegian customers, you answer to Datatilsynet. While the Personal Data Act doesn't explicitly name protocols, it mandates that you implement "appropriate technical and organizational measures" to secure data.

Using standard FTP in 2011 fails the "appropriate measures" test. If a breach occurs and it is discovered you were using cleartext protocols for administration, you are liable. Switch to SFTP. It is free, it is already installed on your Linux server, and it keeps your data private.

Don't risk your reputation for the sake of legacy habits. Disable port 21 today.

Need a sandbox to test your new security configurations? Deploy a high-performance CentOS 6 instance on CoolVDS in under 2 minutes.