FileZilla SFTP With an SSH Key on Windows 11
Set up FileZilla SFTP with an SSH private key on Windows 11. Learn Site Manager settings, key formats, host-key checks, ports and common connection fixes.
Why use an SSH key with FileZilla?
SFTP runs over SSH and can authenticate with a private key instead of a reusable account password. On a Windows workstation this is useful for hosting control panels, VPS servers, development machines and managed servers where administrators disable password logins. FileZilla keeps the connection profile in Site Manager, while the server still decides which key is trusted.
Before you configure the connection
Collect the server hostname, SSH port, username and the private key that belongs to the public key installed on the server. Most SFTP servers listen on port 22, but hosting providers often use a custom port. Confirm the host fingerprint from a trusted source before the first login; the fingerprint is what lets you detect a server impersonation attempt.
Create the SFTP entry in Site Manager
Open Site Manager, create a new site, choose SFTP as the protocol, enter the host and port, and select the logon method that uses a key file. Point FileZilla at the private key stored on the PC. Keep the key in a folder that is not shared by other Windows users and avoid copying it into public cloud-sync folders unless you deliberately protect that location.
Private-key formats on Windows
Modern FileZilla builds can work with common OpenSSH-style keys. If an older key cannot be read, first confirm that it is actually a private key and not the matching .pub file. Converting key formats should be done with trusted SSH tools, and the original should be preserved until the new file is tested. A passphrase-protected key is preferable because possession of the file alone is then not enough to authenticate.
Verify the server host key
On the first connection FileZilla presents the server host key. Compare its fingerprint with the value supplied by the server administrator or hosting dashboard. Do not approve a changed fingerprint automatically on a production server. A changed key can be legitimate after a rebuild, but it can also signal DNS tampering or a machine-in-the-middle attempt.
Troubleshooting key authentication
If the server rejects the key, check the username first; the right key attached to the wrong account still fails. Then verify that the public key is installed in that account authorization configuration and that the server accepts the key algorithm. If FileZilla connects but cannot list a directory, the authentication succeeded and the problem is more likely permissions or the starting path.
A safer Windows workflow
Create one Site Manager entry per environment, use descriptive names such as Production SFTP and Staging SFTP, and avoid saving unnecessary passwords. Back up connection details separately from private keys. For teams, individual keys are easier to revoke and audit than a shared credential.