Stop Broadcasting Your Root Password
It is 2011. If you are still using standard FTP on port 21 to manage your servers, 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. They were puzzled why their site kept getting injected with iframe malware. The culprit wasn't a sophisticated SQL injection; it was a developer updating files from a coffee shop using unencrypted FTP. A simple packet sniffer grabbed the credentials in cleartext.
Latency and uptime matter, but they mean nothing if your server is compromised. In the Nordic hosting market, where trust is our currency, data breaches are fatal. With the Norwegian Personal Data Act (Personopplysningsloven) strictly enforced by Datatilsynet, you cannot afford negligence.
The solution is not FTPS (which is a firewall nightmare); the solution is SFTP (SSH File Transfer Protocol). It is time to shut down the FTP daemon and route everything through the encrypted tunnel you are already using.
The Architecture of SFTP vs. FTP
Standard FTP dates back to 1971. It opens a control channel (port 21) and separate data channels. This archaic design causes massive headaches with modern `iptables` firewalls and NAT configurations. More importantly, it sends everything—username, password, and data—in plain text.
SFTP is a different beast entirely. It is not FTP over SSH; it is a completely separate protocol that runs as a subsystem of the SSH daemon. It uses a single port (usually 22), encrypts the entire session, and piggybacks on the strong authentication methods of OpenSSH.
Pro Tip: Do not confuse SFTP with "SCP". While SCP is great for a quick `scp file.tar.gz user@host:/tmp`, SFTP provides a robust interactive file manipulation interface that modern clients like WinSCP and FileZilla handle gracefully.
Implementation: Configuring OpenSSH on CentOS 5
Most production environments today run CentOS 5 or RHEL 5. By default, OpenSSH is installed, but it might not be optimized for file transfer restrictions. If you are running a CoolVDS instance, you have full root access, so you can tweak the `sshd_config` directly. Shared hosting users are usually out of luck here.
1. The Basic Configuration
Open your config file:
vi /etc/ssh/sshd_config
Ensure the subsystem is defined. In older versions of OpenSSH, it looked like this:
Subsystem sftp /usr/libexec/openssh/sftp-server
However, if you have updated to a newer OpenSSH (4.8p1 or later, which is best practice in 2011), you should change this to use the internal process. This is crucial for performance and for chrooting users later:
Subsystem sftp internal-sftp
2. Jailing Users (ChrootDirectory)
One valid complaint about moving from FTP to SFTP is that SSH users can often browse the entire filesystem. You don't want a web developer snooping around `/etc/`.
With the `Match` directive introduced in recent OpenSSH versions, we can lock users into their home directories without needing complex patch sets or third-party shells like rssh.
Add this to the bottom of your `sshd_config`:
Match Group sftponly
ChrootDirectory %h
ForceCommand internal-sftp
AllowTcpForwarding no
X11Forwarding no
Now, create the group and add a user:
groupadd sftponly
usermod -G sftponly webdev_user
Warning: For `ChrootDirectory` to work, the directory path up to the root must be owned by root and not writable by any other user. If you mess this up, the user will be kicked out immediately upon login. This requires precise permission management—something you can only do effectively on a VPS or Dedicated server.
Performance: The Encryption Tax
Critics argue that SFTP is slower than FTP because of the encryption overhead. In 2005, maybe. In 2011, with modern CPUs (like the Xeons we run in our datacenters), the bottleneck is rarely the CPU. The bottleneck is I/O.
This is where hardware choice becomes critical. Encrypted data streams require random write operations. If your host is running standard SATA drives in a crowded RAID 5 array, your SFTP uploads will crawl. You need high-IOPS storage.
| Feature | Legacy FTP Hosting | CoolVDS (KVM) |
|---|---|---|
| Protocol | Plaintext FTP (Insecure) | SFTP via OpenSSH (Encrypted) |
| Firewalling | Complex (Passive port ranges) | Simple (Port 22 only) |
| Storage Speed | Standard SATA | Enterprise SSD / SAS 15k |
The "CoolVDS" Advantage in Norway
Why does this matter for a server located in Oslo or utilizing the NIX (Norwegian Internet Exchange)? Because latency exacerbates protocol inefficiencies. TCP window scaling helps, but a clean, encrypted, single-port connection is simply more stable across the WAN.
At CoolVDS, we don't oversell our CPU cores. Encryption requires consistent CPU cycles. If you are on a budget VPS where the host node is thrashing due to a "noisy neighbor," your SFTP transfer speeds will fluctuate wildly. We utilize KVM virtualization to ensure strict resource isolation. When your SSH daemon needs to encrypt a 2GB SQL dump, the CPU cycles are there waiting for you.
Furthermore, our storage backend utilizes enterprise-grade SSD caching and high-speed SAS arrays. We are seeing I/O speeds that make standard SATA implementations look like floppy disks. When you are transferring critical backups, that speed difference isn't just a luxury; it's your disaster recovery time objective (RTO).
Conclusion
FTP had a good run, but in the era of sophisticated packet sniffing and strict data privacy laws like Personopplysningsloven, it is a liability. Move your workflow to SFTP. Configure your `sshd_config` correctly to jail your users.
And if you need a platform that gives you the root access to configure security properly, combined with the I/O performance to handle encrypted transfers without breaking a sweat, it is time to upgrade.
Secure your infrastructure today. Deploy a high-performance CentOS instance on CoolVDS in under 60 seconds.