From FTP to SFTP: Secure File Transfer on Shared Hosting and VPS

Most website owners still use plain FTP because “that’s what the designer set up years ago”. It works, it feels familiar, and most hosting control panels still show an FTP section. But in 2025, transferring your site files with unencrypted FTP is like logging in to online banking over HTTP: the data moves, but anyone on the path can read or even alter it. Passwords, configuration files, and customer data are all exposed in clear text. If you care about security, compliance, or simply not getting hacked, switching to SFTP or FTPS is no longer optional – it’s a must.

In this guide, we’ll walk through how secure file transfer really works on both shared hosting and VPS: what SFTP and FTPS are, how they differ, how SSH keys fit into the picture, and what you can realistically do on a basic cPanel account versus a full VPS. The goal is simple: by the end, you’ll know which protocol to use, how to configure your client, and which hosting setup makes sense for your projects – all with practical, real‑world examples from the dchost.com team.

Why Traditional FTP Is No Longer Acceptable

FTP (File Transfer Protocol) is one of the oldest protocols on the internet. It was great in an era where networks were trusted and encryption was rare. Today it has three major problems:

• No encryption: Usernames, passwords, commands and file contents travel in plain text. Anyone on the same Wi‑Fi, in the same office network, or on a compromised router can sniff them.
• Weak authentication: Typically just a username + password that’s reused in other places. Once stolen, attackers can log in at will.
• Messy firewall behaviour: FTP uses separate control and data channels, active/passive modes and wide port ranges, which makes it harder to protect with firewalls and IDS/IPS rules.

On shared hosting, FTP is even riskier because multiple customers share the same server. A single compromised customer PC using an infected FTP client can leak all their credentials to an attacker who then scripts mass logins and malware uploads across dozens of sites on the same platform.

On a VPS, plain FTP introduces an extra service to harden and maintain, and it opens ports you do not really need. Since you already have SSH, it’s almost always better to rely on SFTP instead of running a separate FTP server at all.

In short: plain FTP should be considered deprecated. If your workflow still depends on it, plan a migration now rather than after an incident.

SFTP vs FTPS vs SCP: Understanding Your Options

When people say “secure FTP”, they usually mean one of two very different protocols:

• SFTP – SSH File Transfer Protocol (often mistakenly called “Secure FTP”).
• FTPS – FTP over SSL/TLS, which is the original FTP protocol wrapped in encryption.

There are also other tools like SCP and rsync that build on SSH. Let’s break them down so you can choose the right one.

What Is SFTP?

SFTP (SSH File Transfer Protocol) is a file transfer protocol that runs over SSH. That means:

• Single port: It uses the same port as SSH, typically 22, which is easy to protect with a firewall.
• Strong encryption: It relies on SSH’s modern ciphers and key exchange algorithms.
• Key‑based authentication: You can log in with SSH keys instead of passwords (we’ll cover this in detail shortly).
• File operations built‑in: It supports operations like chmod, chown, symlink, resume uploads, directory listings with metadata, etc.

SFTP is not FTP with encryption; it’s a different protocol entirely. You need an SSH/SFTP server on the hosting side and an SFTP‑capable client (FileZilla, WinSCP, Cyberduck, etc.) on your computer.

On a VPS, SFTP is usually available as soon as SSH is active. On shared hosting, SFTP may be offered as “SSH access”, “SFTP access” or “Secure FTP”; check your provider’s documentation. At dchost.com, our focus is on SSH‑based access methods like SFTP because they align with modern security expectations.

What Is FTPS?

FTPS (FTP over SSL/TLS) is the traditional FTP protocol running inside an encrypted TLS tunnel, similar to HTTPS for the web. There are two variants:

• Explicit FTPS: Client connects to the normal FTP port (21) and then upgrades to TLS with an AUTH TLS command. This is the most commonly supported mode on hosting platforms.
• Implicit FTPS: Client connects to a dedicated FTPS port (often 990) and encryption is enforced from the start. Less common on modern platforms.

FTPS gives you encryption of credentials and data, which is already a huge step up from plain FTP. However, it still inherits FTP’s complexity with multiple ports and passive/active mode, which can complicate firewalls and NAT.

Because FTPS relies on SSL/TLS, you also need to keep an eye on protocol and cipher deprecations, very similar to HTTPS. If you want to go deeper into this topic, you can learn how to stay on top of SSL/TLS protocol updates on your servers.

Where Do SCP and rsync Fit?

SCP (Secure Copy) is a simple, SSH‑based command‑line tool to copy files between hosts. It’s great for quick one‑off transfers but lacks advanced features like resume or directory synchronization.

rsync is another SSH‑friendly tool that syncs directories efficiently by sending only changed blocks. Many teams use rsync over SSH (or SFTP) for automated deployments and backups.

For most website owners and small teams, the practical choices are:

• SFTP for daily interactive work using GUI clients.
• FTPS when SFTP is not available on shared hosting, but TLS is.
• SCP/rsync over SSH for VPS users and DevOps workflows.

Secure File Transfer on Shared Hosting

Shared hosting is where most people encounter FTP for the first time. You typically have a control panel like cPanel or DirectAdmin, and you’re given an FTP username, password, and hostname.

Security‑wise, you’re constrained by what your hosting provider enables. You usually cannot change the SSH configuration or system‑level services, but you can still make much safer choices inside those limits.

What You Can Usually Do on Shared Hosting

On a modern shared hosting platform, you will typically have one or more of these options:

• Plain FTP – almost always available, but should be avoided.
• FTPS (explicit TLS on port 21) – increasingly supported and often enabled by default.
• SFTP via SSH – available if the provider offers SSH access; sometimes limited to higher‑tier plans or upon request.

Here’s how to prioritize them:

1. Use SFTP whenever possible. It gives you strong encryption and the ability to move to SSH keys later.
2. If SFTP is not available, use FTPS (explicit TLS). Make sure your FTP client is configured to “require explicit FTP over TLS”.
3. Disable plain FTP logins if the panel allows it. Some control panels let you enforce TLS for all FTP users.

If you’re running WordPress or another CMS, file transfer security is only one layer of your overall protection. For a broader view, you can review our WordPress security checklist for shared hosting, which covers plugins, WAF, 2FA and backups from a hosting perspective.

Switching an Existing Site from FTP to SFTP or FTPS

The biggest barrier for most people is not technology; it’s habit and misconfigured clients. The good news: switching from FTP to SFTP/FTPS is mostly about changing settings in your client, not your code.

Here’s a typical migration flow using FileZilla as an example (the same logic applies to WinSCP, Cyberduck and others):

1. Check what your hosting account supports. In your control panel or welcome email, look for notes about “SFTP”, “SSH access” or “FTP over TLS”. If unsure, ask support.
2. Create or confirm your FTP/SFTP user. On shared hosting, you usually have a primary account plus optional extra FTP users for specific directories.
3. Update your client protocol:
   • If SFTP is available, set protocol to “SFTP – SSH File Transfer Protocol”, host to your domain or server hostname, and port to 22 (unless your provider uses a custom port).
   • If only FTPS is available, set protocol to “FTP – File Transfer Protocol”, encryption to “Require explicit FTP over TLS”, and port to 21.
4. Test listing and transferring a small file. Confirm you can upload and download without errors.
5. Remove or disable plain FTP entries. Delete saved connections that use unencrypted FTP so you don’t accidentally fall back to them later.

Once you’ve confirmed SFTP or FTPS works, you can keep using your normal workflow – just with a secure tunnel underneath.

Extra Hardening Steps on Shared Hosting

Even though you cannot tune the server itself, you can still make good choices:

• Create separate FTP/SFTP users per project. Do not give one user access to all sites, especially if you share credentials with freelancers.
• Limit each user to the minimum directory needed. Control panels usually let you restrict users to a specific folder.
• Use long, unique passwords and a password manager. Never reuse hosting passwords elsewhere.
• Use 2FA on your control panel. Many compromises start with stolen panel logins, not just FTP.
• Keep regular backups. Even with secure transfer, malware can still arrive via compromised plugins or themes. A realistic backup plan saved many teams we’ve worked with. You can learn how to design a backup strategy with clear RPO/RTO targets for your sites.

Secure File Transfer on a VPS: SSH Keys and Real Control

On a VPS, you are no longer limited to whatever your hosting provider decides. You control the OS, services, users and firewall. That also means more responsibility – but also more power to do things properly.

For secure file transfer on a VPS, the modern baseline is:

• SFTP over SSH only (no plain FTP daemon running at all).
• Key‑based SSH authentication instead of passwords.
• Firewall rules allowing only necessary ports (22 for SSH/SFTP, 80/443 for web, etc.).

If you’d like a wider view of all the things you should harden on a new server, you can read our guide on how to secure a VPS server without leaving any doors open. Here we’ll focus on the SSH and file‑transfer side.

How SSH Keys Work (In Simple Terms)

SSH keys replace your password with a cryptographic key pair:

• You generate a private key and a matching public key on your own computer.
• You keep the private key secret on your machine (optionally protected with a passphrase).
• You upload the public key to the server, into ~/.ssh/authorized_keys for a specific user.

When you connect via SFTP/SSH:

• The server checks if it has your public key.
• It sends a challenge that can only be answered correctly by someone who holds the matching private key.
• If the answer is valid, you’re logged in – without ever sending your password across the network.

This has two major advantages:

• No password to steal over the network. Even if someone sniffs the traffic, there is no reusable secret.
• Protection against brute‑force attacks. SSH keys are practically impossible to guess with today’s computing power, if you use decent key lengths.

For an even deeper dive into SSH hardening (FIDO2 keys, SSH CA, key rotation), we’ve written a separate playbook: VPS SSH hardening without the drama.

Generating SSH Keys on Your Computer

Here’s the high‑level process on common platforms. You do not need to memorize every flag; the important part is understanding the flow.

On Linux and macOS

1. Open a terminal.
2. Run something like:
   ssh-keygen -t ed25519 -C "[email protected]"
3. Accept the default file location (usually ~/.ssh/id_ed25519) and set a strong passphrase.
4. This creates two files:
   • id_ed25519 (private key – keep it secret)
   • id_ed25519.pub (public key – safe to upload to servers)

On Windows (OpenSSH or PuTTY)

• Windows 10/11 with OpenSSH: You can use the same ssh-keygen command in PowerShell as on Linux/macOS.
• Using PuTTY: Use PuTTYgen to generate a new key pair, save the private key (.ppk) and copy the public key text from the PuTTYgen window.

Once you have your keys, you’re ready to install the public key on your VPS.

Configuring SFTP + SSH Keys on a VPS

The exact commands differ between distributions (Ubuntu, Debian, AlmaLinux, Rocky Linux, etc.), but the structure is similar:

1. Create a user for SFTP/SSH access.
   On Linux, something like:
   sudo adduser deploy
2. Create the .ssh directory and set permissions.
   sudo mkdir /home/deploy/.ssh
sudo chmod 700 /home/deploy/.ssh
sudo chown deploy:deploy /home/deploy/.ssh
3. Install the user’s public key.
   Copy the content of your id_ed25519.pub (or equivalent) and paste it into:
   /home/deploy/.ssh/authorized_keys
   Then:
   sudo chmod 600 /home/deploy/.ssh/authorized_keys
sudo chown deploy:deploy /home/deploy/.ssh/authorized_keys
4. Test SSH/SFTP login with the key.
   From your computer:
   ssh deploy@your-vps-ip or configure SFTP in your client using the key file.
5. Optionally restrict the user to SFTP only.
   If this user should not have a full shell, you can configure sshd_config with a Match User block and ForceCommand internal-sftp, plus a ChrootDirectory. This keeps the user confined to a specific directory tree.
6. Once keys work reliably, disable password logins.
   In /etc/ssh/sshd_config, set:
   PasswordAuthentication no
   Then reload SSH. This step dramatically reduces the risk of brute‑force password attacks.

Because these changes affect critical access, always make them via a second terminal session and test before closing your original shell.

Practical SFTP/FTPS Client Configurations

Let’s map this to a few concrete tools.

Configuring FileZilla for SFTP (VPS or Shared Hosting with SSH)

1. Open FileZilla’s Site Manager.
2. Click New Site and give it a name (e.g. “MySite SFTP”).
3. Set Protocol to “SFTP – SSH File Transfer Protocol”.
4. Set Host to your domain or server IP, Port to 22.
5. Set Logon Type to:
   • “Normal” if you still use a password (not ideal for VPS but sometimes necessary on shared hosting).
   • “Key file” if you use SSH keys; then browse to your private key file.
6. Enter your SSH/SFTP username.
7. Click Connect and accept the server’s host key if prompted (verify it if your provider gives you the fingerprint).

Configuring FileZilla for FTPS (Shared Hosting)

1. In Site Manager, click New Site.
2. Set Protocol to “FTP – File Transfer Protocol”.
3. Set Encryption to “Require explicit FTP over TLS”.
4. Set Host to your domain or server IP, Port to 21.
5. Enter your FTP username and password.
6. On first connection, check the certificate details and accept if they match your server.

Most modern FTP/SFTP clients support both SFTP and FTPS in similar ways. The key is to make sure the protocol/encryption settings match what your hosting account offers.

Automating Transfers with SFTP on a VPS

Once you have SSH keys in place, automation becomes much easier. A few real‑world patterns we see often:

• CI/CD deployments: Your GitLab/GitHub pipelines use scp, sftp or rsync -e ssh to push new builds to the VPS without storing passwords in CI secrets.
• Scheduled backups: A cron job on your VPS or backup server pulls/syncs data over SSH to offsite storage. If you’re designing a larger backup system, our article on the 3‑2‑1 backup strategy with automated jobs on cPanel, Plesk and VPS can give you a complete picture.
• Multi‑server sync: SFTP/rsync over SSH keeps web, worker and staging servers in sync in a controlled way.

Because everything rides on SSH, you only need to secure and monitor one entry point instead of juggling FTP and SSH separately.

Security Best Practices for File Transfers

Whether you’re on shared hosting or a VPS, these principles will keep your file transfer layer in good shape.

1. Prefer SFTP Over FTPS When You Can

Both SFTP and FTPS encrypt credentials and data, which is the big win over plain FTP. But SFTP has a few advantages:

• Single port (22) – easier firewall and intrusion detection.
• Same stack as SSH – one set of keys, one set of logs.
• Cleaner protocol – no passive port ranges and oddities.

That said, if your shared hosting only offers FTPS, use it – it’s still a huge improvement over unencrypted FTP.

2. Keep Your TLS and SSH Stacks Updated

On VPS and dedicated servers, you are responsible for keeping OpenSSH and OpenSSL/libressl up to date, and for deprecating weak ciphers and protocols. Deprecated TLS versions (like TLS 1.0/1.1) and weak key exchanges should be disabled.

We’ve covered these changes and timelines in more depth in our article on SSL/TLS security updates and what you must keep up to date on your servers. The same principles apply to FTPS as they do to HTTPS.

3. Segment Access Per Person and Per Project

Never give one all‑powerful account to everyone. Instead:

• For shared hosting, create separate FTP/SFTP users for each site or client, limited to the required directory.
• For VPS, create dedicated Unix users or deploy accounts, each with their own SSH keys and limited permissions.

This way, if one freelancer’s laptop is stolen or one machine gets malware, the blast radius is smaller.

4. Protect the Entry Points: Panels and SSH

Many compromises start with stolen control panel or SSH passwords rather than protocol flaws. Reduce that risk by:

• Enabling 2FA on your hosting panel, domain registrar and any admin dashboards.
• Using SSH keys and disabling password authentication on VPS once keys work reliably.
• Rate‑limiting and firewalling SSH (e.g. allow from your office IPs, use Fail2ban or similar tools).

If you’d like a more complete, calm checklist for panel‑side protections, our guide on hardening cPanel against brute force and malware is a good complement to secure file transfer.

5. Always Assume You’ll Need to Restore

Even with perfect SFTP/FTPS setups, risks remain: compromised plugins, supply‑chain malware, human error. Treat backups as part of your file‑transfer story, not an afterthought:

• Keep multiple generations of backups (daily, weekly, monthly).
• Store at least one copy off‑server.
• Test restores on a staging environment so you know your process works before an emergency.

We’ve seen teams lose days not because they lacked backups, but because they had never practised restoring them. A simple documented runbook beats a “we’ll figure it out” approach every time.

Shared Hosting or VPS: Which Makes Sense for Secure File Transfer?

From a pure file‑transfer perspective, both shared hosting and VPS can be made reasonably secure if you use SFTP or FTPS correctly. The difference is how much control you need and what else you plan to run.

When Shared Hosting Is Enough

Shared hosting is usually the right fit when:

• You run a small business site, blog or brochureware site.
• You’re okay with the provider managing SSH/FTP/FTPS configuration.
• You mainly need one or two users (you and maybe a developer) to upload files.
• You prefer to manage everything via a control panel and use SFTP/FTPS occasionally.

As long as your provider offers SFTP or FTPS, lets you enforce TLS and gives you basic per‑user directory isolation, you can reach a decent security level with good habits.

When a VPS Is the Better Fit

A VPS becomes the better option when:

• You manage multiple projects or clients and need fine‑grained access control.
• You want to enforce SSH keys, disable password logins, and tune SSH/FTPS policies yourself.
• You use CI/CD, staging and automated deployments that benefit from SSH‑based workflows.
• You run custom software stacks beyond what shared hosting allows.

On a VPS from a provider like dchost.com, you can choose your Linux distribution, tune OpenSSH, configure SFTP‑only users, and integrate with your wider monitoring and backup stack. If you’re deciding between shared hosting, managed WordPress or VPS for a broader set of needs, our comparison of web hosting types with real‑world examples can help you pick the right starting point.

Bringing It All Together (and What We Do at dchost.com)

Moving from plain FTP to SFTP or FTPS is one of those upgrades that quietly pays off for years. You don’t get more visitors overnight, and your design does not change, but you eliminate an entire class of password‑stealing and data‑sniffing attacks. On shared hosting, the switch is usually as simple as updating your client settings and enforcing TLS. On a VPS, you can go further with SSH keys, SFTP‑only users, and strict firewall rules that match your security policies.

At dchost.com, we design our shared hosting, VPS, dedicated and colocation services with this layered view in mind: encrypted protocols by default, clear separation between users and projects, and practical guidance so you are not left piecing together security from random forum posts. Whether you’re hosting a single WordPress site or a portfolio of client projects, you can lean on SFTP/FTPS and SSH keys as the backbone of safe file transfers.

If you’re currently on plain FTP, pick one site this week and move it to SFTP or FTPS; once you see how little breaks, you can roll out the change everywhere. And if you’re ready to graduate to a VPS where you control every aspect of SSH, SFTP and automation, our team at dchost.com is here to help you choose the right plan and configure it with a calm, security‑first approach.