Stop Broadcasting Your Root Password to the Entire Coffee Shop

It is 2011. Why are you still using a protocol defined in 1985? Every time you log into your server using standard FTP, you are sending your username and password in plain text across the network. If you are sitting in a café in Grünerløkka on public Wi-Fi, or even on a shared corporate LAN, anyone with a copy of Wireshark or `tcpdump` can rip your credentials out of the air in milliseconds.

With the release of tools like Firesheep late last year, session hijacking and packet sniffing have moved from the realm of elite hackers to script kiddies. If you are managing servers in Norway, you also have the Datatilsynet (Data Protection Authority) to worry about. Under the Personal Data Act (Personopplysningsloven), failing to secure basic data transit could be seen as a lack of required internal control.

There is no excuse. The solution is already installed on your server: SFTP.

SFTP vs. FTPS: Clear the Confusion

Many admins confuse these two. Let's clarify the architecture:

At CoolVDS, we advocate for SFTP. It leverages the existing OpenSSH daemon, meaning one less service to manage, one less port to open in `iptables`, and significantly reduced attack surface.

The Implementation: Chrooted SFTP

The problem with giving a developer SFTP access via SSH is that, by default, they can roam your entire filesystem. They might not have root, but they can see `/etc/passwd` or poke around `/var/www`. We need to lock them into their home directory.

OpenSSH 4.9 and later (standard on our CentOS 5 and Debian 6 templates) supports the `ChrootDirectory` directive natively. No need for messy hacks or third-party shells like `rssh` anymore.

Step 1: Create the Group and User

First, create a group for users who should only have file transfer access, not shell access.

# groupadd sftponly
# useradd -g sftponly -s /bin/false -d /home/jens jens
# passwd jens

Note the `/bin/false`. This ensures that even if they try to SSH in normally, they get rejected. They must use an SFTP client.

Step 2: Configure SSHD

Edit your ssh config. This is where the magic happens. On your CoolVDS instance, open the config:

# vi /etc/ssh/sshd_config

Find the `Subsystem` line. It usually looks like `Subsystem sftp /usr/lib/openssh/sftp-server`. Change it to use the internal helper, which is required for chrooting without copying library files:

Subsystem sftp internal-sftp

At the very bottom of the file, add this block:

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

Step 3: Permissions Architecture

This is where most people fail. For `ChrootDirectory` to work, the directory path must be owned by root and not writable by any other user.

# chown root:root /home/jens
# chmod 755 /home/jens
# mkdir /home/jens/www
# chown jens:sftponly /home/jens/www

Now, `jens` can upload files into the `www` folder, but he cannot go up a level to see your system files.

Step 4: Reload and Verify

Restart the service to apply changes:

# /etc/init.d/ssh reload

Now, test the connection from your local machine. You should see a successful SFTP connection, but an SSH attempt should fail.

Pro Tip: Network latency kills SSH/SFTP performance. The protocol is chatty—it waits for acknowledgment packets. If your server is in the US but your dev team is in Oslo, file transfers will crawl. This is why hosting geographically close to your team matters. CoolVDS infrastructure peers directly at NIX (Norwegian Internet Exchange) in Oslo, keeping latency in the single digits for local transfers.

Why Virtualization Matters for Security

You might ask, "Can't I just do this on shared hosting?"

Technically, maybe. But shared hosting often runs older, unpatched kernels or restricts your ability to modify `sshd_config`. Furthermore, shared hosts often run FTP services that are vulnerable to cross-site symlink attacks.

At CoolVDS, we use KVM virtualization. Unlike OpenVZ containers where you share a kernel with every other customer (and potentially their exploits), KVM gives you a dedicated kernel. You have full control to harden SSH, implement IP whitelisting via `iptables`, and configure the exact encryption ciphers you trust. Security is not a feature you request; it is an architecture you build.

Stop risking your data with protocols from the 80s. Spin up a secure, KVM-based VDS today and lock down your file transfers.