FileZilla SFTP with SSH Keys: A Practical Replacement for Plain FTP

The problem: your deployment still speaks cleartext

Plain FTP sends your username, password, and every file you transfer in cleartext. Anyone on the path between you and the server can read all of it. If you already use FileZilla, you don't need a new tool to fix this — you need to change one dropdown and set up key-based login.

The useful takeaway: FileZilla Client supports SFTP (SSH File Transfer Protocol) out of the box. SFTP runs over a single encrypted SSH connection, usually on port 22, which also sidesteps FTP's awkward multi-connection behavior that makes firewalls painful. For almost every new setup, SFTP should be your default.

Why SFTP beats FTP (and usually FTPS too)

FileZilla offers three protocols: FTP, FTPS (FTP over TLS), and SFTP. They are not interchangeable:

• FTP — no encryption at all. FileZilla itself warns you when a server offers only this. Treat that warning as a stop sign.
• FTPS — encrypted, but still uses FTP's separate control and data connections, which means firewall and NAT rules get complicated.
• SFTP — a completely different protocol tunneled through SSH. One port, one encrypted channel, and it can authenticate with SSH keys instead of passwords.

Key-based login matters because a private key file is far harder to phish or brute-force than a typed password, and you can revoke it server-side without touching anything else.

Setting up a key-based site in Site Manager

Site Manager (File → Site Manager, or Ctrl+S) is where repeatable connections live. Create a new site and set:

• Protocol: SFTP – SSH File Transfer Protocol
• Host: your server's hostname or IP, Port: 22
• Logon Type: Key file
• User: your SSH username
• Key file: browse to your private key

One format gotcha: on Windows, FileZilla works with PuTTY-format (.ppk) keys. If you have an OpenSSH-format key (the kind ssh-keygen produces), FileZilla will offer to convert it when you select the file. Exact behavior varies by version and platform, so confirm what your installed copy accepts before writing this into team documentation.

Worked example — a deployment account on a web server:

Protocol:  SFTP
Host:      deploy.example.com
Port:      22
Logon Type: Key file
User:      deploy
Key file:  C:\Users\you\.ssh\deploy_key.ppk

Click Connect. On first connection you'll get the host key dialog — don't skip past it.

The host key dialog is a security control, not a nuisance

FileZilla uses trust-on-first-use: the first time you connect, it shows the server's host key fingerprint and asks you to trust it. If you blindly click OK, you've accepted whatever server answered — including a potential man-in-the-middle.

The right habit: get the fingerprint out-of-band before first connect. On the server itself (or via your provider's console), run:

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Run this on the server as a user with read access to /etc/ssh. Compare the printed fingerprint with what FileZilla shows. If they match, check "Always trust this host" and connect. If they don't, stop — something is wrong.

After that, daily work is straightforward: the transfer queue handles multi-file deployments, and View → Directory Comparison helps you spot drift between local and remote trees before you push.

Honest trade-offs

• Credential storage. Passwords saved in Site Manager have historically been stored on disk in recoverable form (plaintext or base64) in FileZilla's config files. Key-based login avoids storing a password at all — one more reason to prefer it. Check your version's settings for master password support if you must save passwords.
• No real scripting. FileZilla's command-line interface is minimal. If you need automated, unattended transfers, look at WinSCP scripting or lftp instead.
• Client vs. Server. This post is about FileZilla Client. FileZilla Server is a separate product with its own configuration and security history — don't assume anything here applies to it.

Verify it worked

After setup, confirm three things: the connection log shows the SFTP handshake and key authentication (not password); the remote directory listing loads; and a small test file transfers and arrives intact (compare sizes, or checksums for anything important). If the server logs are available to you, /var/log/auth.log on the server will show the publickey authentication event.

The actionable close: open Site Manager today, switch any plain-FTP entries to SFTP, and move authentication to a key file. It's a fifteen-minute change that removes cleartext credentials from your workflow entirely.