Stop Broadcasting Passwords: Why Your Norway VPS Needs SFTP Now

It is 2012. If you are still running a standard FTP daemon listening on port 21, you might as well print your root password on a billboard in downtown Oslo. I have seen too many "secure" environments breached not by zero-day kernel exploits, but by a simple packet sniffer running on a compromised coffee shop Wi-Fi where a developer decided to upload a hotfix.

FTP was designed in an era where the internet was a friendly village. It sends everything—usernames, passwords, data—in clear text. Anyone with tcpdump or Wireshark between you and your server owns your infrastructure.

For serious system administrators managing VPS Norway infrastructure, moving to SFTP (SSH File Transfer Protocol) isn't an option; it is mandatory. It runs over the SSH protocol, encrypting the entire session. No more firewall headaches with passive ports. No more clear-text credentials. Here is how to configure it correctly on your CoolVDS instance without locking yourself out.

The Compliance Nightmare: Datatilsynet is Watching

In Norway, we operate under the Personopplysningsloven (Personal Data Act). The Data Inspectorate (Datatilsynet) is clear about the responsibility to secure personal data. If you are hosting customer data on a server and you transfer that data using unencrypted FTP, you are likely in violation of the requirement for "appropriate technical security measures."

When you deploy on CoolVDS, you get full root access on KVM or Xen virtualization. This means you control the encryption layer. Shared hosting environments often restrict your ability to modify SSH configurations. We don't. You are the architect.

Step 1: The Architecture of a Secure SFTP Setup

We are not just enabling SFTP; we are locking it down. We want a setup where:

• Users can transfer files securely.
• Users cannot get a shell prompt.
• Users are locked (chrooted) to their specific web directory.

This relies on the internal-sftp subsystem found in OpenSSH (versions 4.8+). Most CoolVDS templates running CentOS 6 or Debian 6 Squeeze come with OpenSSH 5.x, which supports this natively.

Step 2: Configuring sshd_config

First, back up your config. Always back up. If you break SSH, you will need to use the CoolVDS VNC console to fix it, which costs time.

Open /etc/ssh/sshd_config with vi or nano. We need to comment out the default sftp subsystem and replace it with the internal one. This eliminates the need for copying binaries into the chroot jail.

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

Next, add the matching rules at the very bottom of the file. This tells SSH: "If a user belongs to the group sftponly, force them into SFTP mode and lock them in their home directory."

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

Pro Tip: The ChrootDirectory %h directive is powerful but picky. The directory defined as the user's home must be owned by root:root and not writable by the user. If permissions are wrong, the connection will drop instantly with a "broken pipe" error.

Step 3: Creating the User and Group

Now, let's create the group and a test user. This applies to any standard Linux system, whether it is RHEL 6 or Ubuntu 10.04 LTS.

groupadd sftponly
useradd -g sftponly -s /bin/false -d /var/www/clients/client1 webdev1
passwd webdev1

Setting the shell to /bin/false is a second layer of defense. Even if the SSH configuration fails, the user has no login shell.

Step 4: The Critical Permissions Setup

This is where 90% of admins fail. The chroot requirement is strict. The directory you traverse into must be root-owned. The directory you write to must be user-owned.

Let's assume your website structure is /var/www/clients/client1/html.

# Create the directory structure
mkdir -p /var/www/clients/client1/html

# Lock the chroot root
chown root:root /var/www/clients/client1
chmod 755 /var/www/clients/client1

# Give the user the subdirectory
chown webdev1:sftponly /var/www/clients/client1/html
chmod 755 /var/www/clients/client1/html

Now, the user webdev1 logs in. The SSH daemon chroots them to /var/www/clients/client1. They see a folder named html. They can upload files into html, but they cannot delete the parent folder or wander up to /etc to read your config files.

Step 5: Restart and Verify

Restart the SSH daemon to apply changes.

# On CentOS/RHEL 6
service sshd restart

# On Debian 6 / Ubuntu
/etc/init.d/ssh restart

Check your /var/log/secure or /var/log/auth.log immediately. If you made a syntax error, the daemon might not come back up. (You kept that VNC console tab open, right?)

Why Performance Matters Here

Encryption adds overhead. Every byte transferred via SFTP is encrypted and decrypted. On older hardware or overloaded nodes, this can throttle transfer speeds. This is why underlying hardware matters.

At CoolVDS, we don't oversell our CPU cores. When you initiate a large transfer of static assets or a database dump, our KVM instances provide the dedicated cycles needed for the AES encryption math. Combined with our high-performance SSD storage (a significant upgrade over the spinning SATA disks common in budget hosting), your I/O throughput remains high even during encrypted transfers.

Comparison: FTP vs. SFTP on CoolVDS

Closing the Hole: IPTables

Once you have confirmed SFTP works using a client like FileZilla or WinSCP, kill the legacy. Remove the FTP server and close the port.

# Stop the service
service vsftpd stop
chkconfig vsftpd off

# Update IPTables to drop port 21
iptables -D INPUT -p tcp --dport 21 -j ACCEPT
service iptables save

Security is not a product; it is a process. Moving to SFTP is a fundamental step in hardening your Linux environment. It ensures that when you push code from Oslo to a server in Frankfurt, the data remains yours.

Do not let legacy protocols compromise your uptime or your reputation. Deploy a secure, SSD-backed KVM instance on CoolVDS today and configure it right from day one.