How to replace FTP with SFTP for secure file transfers?

To replace FTP with SFTP, you connect to your server using the SSH File Transfer Protocol on the SSH port (usually 22) instead of FTP on port 21, ideally with an SSH key rather than a password. On your own server, you make sure OpenSSH is installed, create restricted SFTP-only users where needed, test the new connection, and then disable or uninstall the FTP service. Your usual file transfer client, such as FileZilla, WinSCP, Cyberduck, or the sftp command, works with SFTP out of the box.

FTP was designed in an era when nobody worried about someone watching network traffic. It sends your username, password, and files in plain text. This guide explains the difference between FTP, FTPS, and SFTP, then walks you through switching over, both as a user connecting to a host and as an administrator configuring a Linux server. You'll also see how to lock SFTP users into a single directory and how to handle WordPress updates without FTP.

Why Plain FTP Is a Security Risk

FTP has several built-in weaknesses:

• Unencrypted credentials: Your username and password travel across the network in plain text. Anyone on the same Wi-Fi, a compromised router, or a malicious network operator can capture them.
• Unencrypted files: The files you upload, including configuration files containing database passwords, can be read in transit.
• No integrity protection: Data can be altered in transit without either side noticing.
• Firewall headaches: FTP uses separate control and data connections, with passive mode requiring a range of extra ports to be open.
• Common attack target: FTP servers are constantly probed with password-guessing attacks, and stolen FTP credentials are a classic way malware ends up on websites.

Many site infections begin when a developer's computer is infected with credential-stealing malware that reads saved FTP passwords from their client, or when credentials are sniffed on public Wi-Fi. Switching to SFTP with keys closes off most of these routes.

FTP vs FTPS vs SFTP

The names are confusingly similar, so it's worth being clear:

• FTP: The original File Transfer Protocol. No encryption. Port 21 plus data ports.
• FTPS: FTP with TLS encryption added (the same technology used by HTTPS). It encrypts traffic but keeps FTP's multi-port design and needs a certificate on the server. Often shown as "FTP over explicit TLS" in clients.
• SFTP: The SSH File Transfer Protocol. Despite the name, it's not FTP at all. It runs inside an SSH connection on a single port, encrypts everything, and supports SSH key authentication.

For most websites, SFTP is the better choice. It's usually already available wherever SSH is, uses one port, and supports keys. FTPS is a reasonable fallback on hosts that don't offer SSH access.

Part 1: Switching as a User

If you're on shared or managed hosting, your host handles the server side. You just need to change how you connect.

Check Whether Your Host Supports SFTP

Look in your hosting control panel or documentation for "SSH access" or "SFTP". Most reputable hosts offer it, though some require you to enable SSH for your account first. You'll need:

1. Hostname: Often your domain name or a server hostname given by your host.
2. Port: Usually 22, but some hosts use a custom port.
3. Username: Often your control panel username or a dedicated SFTP user.
4. Authentication: A password or, better, an SSH key.

Create an SSH Key

A key pair is far stronger than a password and can't be sniffed or guessed. On macOS, Linux, or Windows 10/11 (in PowerShell or Terminal):

ssh-keygen -t ed25519 -C "you@example.com"

Press Enter to accept the default location and set a passphrase when prompted. This creates two files:

• ~/.ssh/id_ed25519: your private key. Never share or upload it.
• ~/.ssh/id_ed25519.pub: your public key. This is what you add to the server.

Upload the public key through your hosting panel (for example, Security > SSH Access > Manage SSH Keys in cPanel, then authorise it), or, if you already have password access to a Linux server, copy it across with:

ssh-copy-id -i ~/.ssh/id_ed25519.pub username@example.com

Connect With FileZilla

1. Open Site Manager from File > Site Manager.
2. Click New Site and give it a name.
3. Set Protocol to SFTP - SSH File Transfer Protocol.
4. Enter the host and port (leave the port blank for 22).
5. Set Logon Type to Key file, enter your username, and browse to your private key. FileZilla may offer to convert an OpenSSH key; accept if prompted.
6. Click Connect. The first time, you'll be asked to confirm the server's host key fingerprint. Compare it with the fingerprint your host publishes if possible.

FileZilla stores saved passwords in a configuration file on your computer. If you use password authentication, set a master password under Edit > Settings > Interface > Passwords so they're encrypted.

Connect With WinSCP or Cyberduck

• WinSCP (Windows): Choose SFTP as the file protocol, enter host and username, then open Advanced > SSH > Authentication and select your private key. WinSCP uses PuTTY's .ppk format and can convert OpenSSH keys for you.
• Cyberduck (macOS and Windows): Choose SFTP (SSH File Transfer Protocol) in the connection dialog and select your SSH private key.

Connect From the Command Line

The sftp command is built into macOS, Linux, and modern Windows:

sftp -i ~/.ssh/id_ed25519 -P 22 username@example.com

Once connected, common commands include:

pwd                      # show remote directory
lcd ~/Sites/mysite       # change local directory
put index.html           # upload a file
get backup.sql.gz        # download a file
put -r wp-content/themes/mytheme   # upload a folder
exit

For syncing whole folders, rsync over SSH is often faster because it only transfers changed files:

rsync -avz -e "ssh -i ~/.ssh/id_ed25519" ./public/ username@example.com:/var/www/example.com/public/

Always do a dry run with --dry-run first when you're syncing to a live site, especially if you add --delete.

Remove Old FTP Credentials

Once SFTP works:

• Delete saved FTP sites from your client so old passwords aren't stored on your computer.
• Delete FTP accounts you no longer need in your hosting panel.
• Change the main account password if it was ever used over plain FTP, since it may have been exposed.

Part 2: Switching on Your Own Linux Server

If you manage a VPS or dedicated server, you control both sides. The steps below use Ubuntu or Debian with OpenSSH.

Step 1: Confirm OpenSSH Is Running

Most servers already have OpenSSH installed. Check:

sudo systemctl status ssh

On RHEL, Rocky Linux, or AlmaLinux, the service is called sshd. If it's missing on Debian or Ubuntu:

sudo apt update
sudo apt install openssh-server

SFTP support is built into OpenSSH through the internal-sftp subsystem, so there's nothing extra to install.

Step 2: Create a Group for SFTP-Only Users

Often you want someone, such as a designer or a deployment tool, to upload files without getting a full shell on the server. A dedicated group makes this easy to manage:

sudo groupadd sftponly

Step 3: Create a Restricted User

Create a user who can't log in to a shell:

sudo useradd -m -g sftponly -s /usr/sbin/nologin designer
sudo passwd designer

If you'll use key-based login only, you can skip setting a password (or lock it with sudo passwd -l designer after adding a key).

Step 4: Set Up the Chroot Directory

A chroot locks the user into a directory so they can't browse the rest of the server. OpenSSH has strict rules here: the chroot directory and every directory above it must be owned by root and not writable by anyone else. The user then gets a writable subdirectory inside it.

sudo mkdir -p /srv/sftp/designer/uploads
sudo chown root:root /srv/sftp/designer
sudo chmod 755 /srv/sftp/designer
sudo chown designer:sftponly /srv/sftp/designer/uploads
sudo chmod 755 /srv/sftp/designer/uploads

If the user needs to work on a website, a common pattern is to bind-mount the site directory into their chroot:

sudo mkdir -p /srv/sftp/designer/site
sudo mount --bind /var/www/example.com/public /srv/sftp/designer/site

To make the bind mount survive reboots, add a line to /etc/fstab:

/var/www/example.com/public  /srv/sftp/designer/site  none  bind  0  0

Make sure file ownership and group permissions on the site directory let the SFTP user write where they need to, and nowhere else.

Step 5: Add SSH Keys for the User

Because the user's home directory is outside the chroot, place their authorised keys in a location sshd can read:

sudo mkdir -p /etc/ssh/authorized_keys
sudo nano /etc/ssh/authorized_keys/designer

Paste their public key, then lock down the permissions:

sudo chown root:root /etc/ssh/authorized_keys/designer
sudo chmod 644 /etc/ssh/authorized_keys/designer

Step 6: Configure sshd

Before editing, keep your current SSH session open and make a backup of the config. A mistake in sshd_config can lock you out.

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

Open /etc/ssh/sshd_config and find the existing Subsystem sftp line (on Debian and Ubuntu it usually points at /usr/lib/openssh/sftp-server). Change it to use the in-process SFTP server, which works inside a chroot without extra binaries:

Subsystem sftp internal-sftp

Keep only one Subsystem sftp line, since duplicate definitions cause errors. Then add this block at the very end of the file. Match blocks apply to every line that follows them, which is why they belong at the bottom rather than in a drop-in file that gets included near the top:

Match Group sftponly
    ChrootDirectory /srv/sftp/%u
    ForceCommand internal-sftp
    AuthorizedKeysFile /etc/ssh/authorized_keys/%u
    PasswordAuthentication no
    AllowTcpForwarding no
    X11Forwarding no
    PermitTunnel no

Test the configuration before reloading:

sudo sshd -t

No output means the syntax is valid. Then reload:

sudo systemctl reload ssh

On RHEL-based systems, use sudo systemctl reload sshd.

Step 7: Test the Connection

From your computer, in a new terminal (keep the admin session open):

sftp -i ~/.ssh/designer_key designer@example.com

The user should land in / of their chroot, see only uploads and site, and be unable to cd above it. Trying ssh designer@example.com should fail with a message that only SFTP is allowed, or disconnect immediately.

If the connection closes right after authentication, check the logs:

sudo journalctl -u ssh --since "10 minutes ago"

The most common error is "bad ownership or modes for chroot directory", which means one of the directories above the chroot isn't owned by root or is group-writable.

Step 8: Harden SSH Overall

While you're in the SSH config, consider these widely recommended settings for all users:

PermitRootLogin prohibit-password
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
MaxAuthTries 4

Only disable password authentication after confirming that every user who needs access has a working key. Test in a second session before closing your current one. Tools like Fail2Ban can also block IPs that repeatedly fail to log in.

Step 9: Disable or Remove the FTP Server

Once everyone has moved to SFTP, turn FTP off. If you used vsftpd:

sudo systemctl disable --now vsftpd
sudo apt remove vsftpd

For ProFTPD or Pure-FTPd, replace the service and package names accordingly. Then close port 21 and any passive port range in your firewall. With UFW:

sudo ufw status numbered
sudo ufw delete allow 21/tcp

Double-check that the rule allowing SSH remains in place before making firewall changes, so you don't cut off your own access.

What About WordPress Updates Without FTP?

WordPress sometimes asks for FTP credentials when it can't write to its own files. That usually means file ownership is wrong, not that you need FTP. On a correctly configured server where PHP runs as the site's owner, WordPress writes files directly.

If you want WordPress to use SSH instead, it supports an SSH2 transport when the PHP ssh2 extension is installed. In wp-config.php, above the "That's all, stop editing!" line:

define( 'FS_METHOD', 'ssh2' );
define( 'FTP_HOST', 'localhost' );
define( 'FTP_USER', 'siteuser' );
define( 'FTP_PUBKEY', '/home/siteuser/.ssh/id_ed25519.pub' );
define( 'FTP_PRIKEY', '/home/siteuser/.ssh/id_ed25519' );

In most cases, though, fixing ownership so PHP-FPM runs as the site user and setting FS_METHOD to direct is simpler and just as safe. You can also manage updates entirely with WP-CLI over SSH:

wp core update
wp plugin update --all

Best Practices for Secure File Transfers

• Prefer keys over passwords: Protect private keys with a passphrase and use an SSH agent so you don't type it constantly.
• One account per person: Never share credentials. It makes access easy to revoke and audit.
• Least privilege: Chroot contractors to the directories they need, and give them no shell.
• Verify host keys: When your client asks you to confirm a fingerprint, check it rather than clicking through. It protects you from man-in-the-middle attacks.
• Remove access promptly: Delete keys and users as soon as someone no longer needs them.
• Consider deployments over manual uploads: Git-based deployments or CI pipelines leave a clear history and reduce ad-hoc file changes on production.

---

FAQ: Replacing FTP With SFTP

---

Conclusion

Replacing FTP with SFTP is one of the easiest security upgrades you can make. It encrypts your credentials and files, works on a single port, and supports SSH keys that can't be sniffed or guessed. For most people, the switch is simply a matter of changing the protocol in their file transfer client and adding a key.

On your own server, take the extra steps to create chrooted SFTP-only users for anyone who doesn't need a shell, test the configuration carefully with a session left open, and then shut down the FTP service and close its ports. Once it's done, you'll have one secure way into your server instead of an old, leaky one that attackers have been exploiting for decades.