SFTP login fails with "No supported authentication methods available (server sent: publickey)" or "Permission denied (publickey)"

This failure almost always arrives the same way: somebody sets up an SFTP account with a password, the client refuses to connect, and the error blames public keys, for an account that has no public key and was never meant to use one. The message is not lying, but it does not mean what it appears to mean. In most cases it means the server offered password authentication, the client's password attempt failed, and the server then withdrew that method, leaving only publickey in the list it reports back. The real fault is whatever made the password attempt fail, and it is very often not the password.

These are the messages this article covers, as the clients print them:

Error:  Disconnected: No supported authentication methods available (server sent: publickey)
Error:  Could not connect to server

FATAL ERROR: No supported authentication methods available (server sent: publickey)

Error:  Disconnected: No supported authentication methods available (server sent: )

Permission denied (publickey).

Server refused our key
Server refused public-key signature despite accepting key!

This article is about the CompleteFTP server rejecting an SFTP, SCP or SSH login. If you are using the edtFTPj/PRO or edtFTPnet/PRO client libraries to connect out to somebody else's server, see "Errors that look similar but are a different problem" near the end.

The short version

1. Set the server logging level to Debug and reproduce the failure. Without a debug log covering the failure you are guessing; every cause below looks identical from the client.
2. In Diagnostics.log, find the first line for that session reading Sent SSH_MSG_USERAUTH_FAILURE: methods=…. That list is the methods your configuration actually allows for that user. Later lines show a shrinking list and are misleading.
3. If that first list contains password, the configuration is fine and something failed the password attempt. Look immediately above and below for one of: Incorrect password, not found, found but not available on site, has no SSH services enabled, home directory does not exist, does not have permission to change into home directory.
4. If that first list does not contain password, the configuration is the problem. Check the authentication methods in both places, the site's SFTP settings and the user's properties (Enterprise MFT only), and remember that a Windows or Active Directory user can never log in without a password.
5. If the client reports (server sent: ) with nothing after the colon, the server had no methods left at all. See the table below.

Command line equivalent, which is the only interface on Linux:

completeftp monitor set logging.level=Debug
sudo grep -n "SSH_MSG_USERAUTH_FAILURE\|Removed authentication method\|not found\|Incorrect password" \
     /var/log/completeftp/Diagnostics.log
completeftp monitor set logging.level=Information

What the client's message actually tells you

No supported authentication methods available (server sent: X) is produced by PuTTY, and therefore also by WinSCP and by FileZilla, whose SFTP support is built on PuTTY's code. X is copied verbatim from the server's last SSH_MSG_USERAUTH_FAILURE packet. OpenSSH's sftp and ssh print Permission denied (publickey). in the same situation, with the same list in the brackets.

The mechanism is visible in the log. After any authentication attempt that cannot be retried, the server withdraws that method for the rest of the session and records Removed authentication method 'password'. The list sent in the next failure packet is what is left, not what is configured. This is why a single wrong password on a password-only account can produce a message that names only publickey.

The one exception, and the reason step 2 above matters: the first none probe that PuTTY and OpenSSH send before trying anything is deliberately ignored (Auth method 'none' ignored) and removes nothing. So the first Sent SSH_MSG_USERAUTH_FAILURE: methods=… line in a session is an accurate report of the configured, effective method set.

How CompleteFTP decides which methods to offer

Two settings combine, and both must permit a method:

The effective set is the intersection. A user's setting defaults to all three methods, so on Standard and Professional the site setting governs everyone.

There are three values, and their behaviour is less symmetrical than the names suggest:

The server computes two internal flags from the effective set, and both appear in the debug log:

2026-07-30 09:14:02,118 DEBUG SSHAuthService [Session.12:Default Site.22::192.168.1.50] Site: NeedPK=False, NeedPassword=False
2026-07-30 09:14:02,214 DEBUG SSHAuthService [Session.12:Default Site.22:sftpuser:192.168.1.50] User sftpuser: NeedPK=True, NeedPassword=True

NeedPK=True means a public key is mandatory, and is set when the plain Password value is absent from the effective set. NeedPassword=True means a password is mandatory, and is set when the plain PublicKey value is absent. That gives:

The practical consequence is worth stating plainly: PublicKeyAndPassword only forces both factors when it is the only value selected. Selecting it alongside Password does not strengthen anything, it leaves password-only logins working and breaks key-only logins. This combination is a common cause of "the key works for one account and not the other".

When both factors are required and only one has succeeded, the server logs a partial success and the client reports Authenticated with partial success or further authentication required:

2026-07-30 09:14:03,006 DEBUG PasswordAuthentication [Session.12:Default Site.22:sftpuser:192.168.1.50] Partial success - also require publickey
2026-07-30 09:14:03,007 DEBUG SSHAuthService [Session.12:Default Site.22:sftpuser:192.168.1.50] Sent SSH_MSG_USERAUTH_FAILURE: methods=publickey,partial=True

Changing the settings

Using CompleteFTP Manager

For the site:

1. Open the Sites panel (Enterprise MFT) or the Settings panel (Standard and Professional).
2. In the site's property grid, expand the SFTP / SCP category, labelled just SFTP in Standard Edition. Beneath it, expand Advanced SFTP/SCP Settings, which is labelled Advanced SFTP Settings in Standard Edition.
3. Open Authentication methods and tick the values you want.
4. Click APPLY CHANGES. Nothing takes effect until you do, and this is the single most commonly missed step in the whole procedure.

The manager will warn you if the result cannot work. Clearing both Password and PublicKeyAndPassword on a Windows user raises:

Windows users will not be able to log in unless Password or PublicKeyAndPassword is enabled.

and clearing everything raises a "no authentication methods selected" warning. If you have ever dismissed either of those without reading it, that is worth re-checking first.

For a user's keys, in any edition from Standard up: select the user, click the ellipsis (...) next to Public keys to open Manage Public Keys, then import the public key they sent you or generate a keypair. Standard Edition allows only one key per algorithm:

Only one key of each type is allowed in CompleteFTP Standard Edition.

Professional Edition and Enterprise MFT allow several, which is what makes key rotation possible without a gap.

Using the CLI

# what the site allows
completeftp site show "Default Site" sshAuthMethods

# password and key each sufficient on their own
completeftp site set "Default Site" sshAuthMethods="Password,PublicKey"

# genuinely require both factors. Note that this value must stand alone
completeftp site set "Default Site" sshAuthMethods="PublicKeyAndPassword"

# per-user (stored and enforced in every edition; see the warning below)
completeftp user show sftpuser sshAuthMethods
completeftp user set sftpuser sshAuthMethods="Password"

# keys
completeftp user key show sftpuser
completeftp user key add sftpuser "ssh-ed25519 AAAAC3Nza... user@workstation"
completeftp user key remove sftpuser 0

# protocol enablement for the user
completeftp user set sftpuser sftpEnabled=true

Values are comma-separated and matched case-insensitively; all is accepted as a shorthand for every value. An unrecognised value is rejected with Invalid value, <what you typed> rather than silently ignored. The same property names work from JSS via system.getConfig2().

On Linux the CLI is the administration interface and works out of the box. On Windows the admin CLI is not enabled by default. See the companion article on debug logging for how to turn it on.

A trap on Standard and Professional. The per-user Methods (SSH) field is only displayed in Enterprise MFT, but the server enforces whatever value is stored regardless of edition, in Standard, Professional and Enterprise MFT alike. So if a configuration was built under an Enterprise MFT trial, or on a server that now runs Standard or Professional, per-user restrictions set at that time are still in force and no longer visible in the manager. Read them back with completeftp user show <user> sshAuthMethods, which works in every edition. This is the usual explanation when two apparently identical accounts behave differently and nothing in the manager accounts for it.

Reading the debug log

Set the logging level to Debug, close the manager so its own admin sessions don't clutter the file, reproduce the failure, then read Diagnostics.log:

• Windows: C:\ProgramData\Enterprise Distributed Technologies\Complete FTP\Logs\Diagnostics.log
• Linux: /var/log/completeftp/Diagnostics.log

Check that the file actually spans the moment of the failure before you send it anywhere. A log that does not contain the failure is the most common reason a support round trip is wasted.

Every line carries a session tag of the form [Session.{n}:{site}.{port}:{user}:{client-IP}], so you can follow one attempt through the file by its session number. The loggers that matter here are SSHAuthService, AuthMethods, PasswordAuthentication, PublicKeyAuthentication, KeyVerifier, SocketListener and AutoBanner.

A successful password login looks like this:

2026-07-30 09:20:11,004 DEBUG AuthMethods [Session.31:Default Site.22::192.168.1.50] Valid authentication types: All
2026-07-30 09:20:11,004 DEBUG AuthMethods [Session.31:Default Site.22::192.168.1.50] Adding password authentication
2026-07-30 09:20:11,005 DEBUG AuthMethods [Session.31:Default Site.22::192.168.1.50] Adding publickey authentication
2026-07-30 09:20:11,181 DEBUG SSHAuthService [Session.31:Default Site.22::192.168.1.50] Auth request - user=sftpuser, service=ssh-connection, method=none
2026-07-30 09:20:11,181 DEBUG SSHAuthService [Session.31:Default Site.22:sftpuser:192.168.1.50] Auth method 'none' ignored
2026-07-30 09:20:11,182 DEBUG SSHAuthService [Session.31:Default Site.22:sftpuser:192.168.1.50] Sent SSH_MSG_USERAUTH_FAILURE: methods=password,publickey,partial=False
2026-07-30 09:20:13,447 DEBUG PasswordAuthentication [Session.31:Default Site.22:sftpuser:192.168.1.50] password auth succeeded
2026-07-30 09:20:13,447 DEBUG SSHAuthService [Session.31:Default Site.22:sftpuser:192.168.1.50] Sent SSH_MSG_USERAUTH_SUCCESS

These are the messages to search for, and what each one means:

Note that all four Login failed: … messages above are emitted from the password path, after the password itself has been accepted. A correct password with a broken home folder therefore produces exactly the same client-side error as a wrong password.

When it doesn't work

Ordered by how often each appears in support tickets.

1. The password attempt failed and the message named publickey instead. By far the most common case, and the reason the error is so misleading. Confirm from the first Sent SSH_MSG_USERAUTH_FAILURE line that password was offered, then look for the actual reason in the table above. Reset the password to something short and unambiguous and retry before assuming anything more exotic.

2. Only one of several apparently identical accounts works. Compare the working and failing accounts field by field, including the ones you did not set: Sites membership, SFTP enabled, Enabled, Expiry date, home folder, and, if the configuration ever ran under Enterprise MFT and sshAuthMethods read back through the CLI. In practice the difference is usually the home folder or site membership, not the credentials.

3. The change was never applied. In the manager, nothing reaches the server until APPLY CHANGES is clicked. If the button is still enabled, the server is still running the old configuration. The CLI and JSS applyChanges() do not have this problem.

4. The user is a Windows or Active Directory account, and you wanted key-only. This cannot be done, and it is not a CompleteFTP setting. A Windows-authenticated account is never treated as fully authenticated by a key alone: the password step is always required as well, because Windows itself needs the password to issue a logon token for the account. The options are:

• accept PublicKeyAndPassword and have the client supply both; or
• create a non-Windows user (an account internal to CompleteFTP) instead, which can authenticate by key alone. Internal users run as the local SYSTEM account on Windows, so grant SYSTEM access to any network share their home folder points at.

If the site's methods are set to PublicKey only and a Windows user connects with a valid key, the key verifies, the mandatory password step has nothing to fall back on, and the log shows Sent SSH_MSG_USERAUTH_FAILURE: no more auth methods available: partial=True. The client reports an empty (server sent: ).

5. Public key authentication is only enabled in one of the two places. The site setting and the user setting are intersected. This is documented, but the user half is invisible outside Enterprise MFT, which is why it is worth reading back with the CLI rather than trusting the manager.

6. The key is registered but is not the key being presented. failed to verify RSA (multi) means the account has RSA keys and none of them matched. PuTTY and WinSCP report this as Server refused our key, or, if the key was accepted in the offer phase and then failed signature verification, Server refused public-key signature despite accepting key!. Two habits cause it: pasting the private key where the public key belongs, and regenerating a keypair on the server after the client has already been given the old private key. The Manage Public Keys dialog has no fingerprint display, so compare by exporting: use Export the selected key in OpenSSH format and check it against the public half of the key the client is actually presenting. Or, from the CLI, completeftp user key show <user>.

7. The client is presenting a key you did not expect. FileZilla holds private keys globally under Edit → Settings → SFTP, and offers them on every connection regardless of the site's logon type. If a user has a key loaded there, their connection tries publickey first, that attempt fails against an account with no key (RSA public key not set for user), the method is removed, and any subsequent password problem then reports an empty method list. Removing the unrelated key from FileZilla's settings fixes connections that "only fail from one machine".

8. Hardening the site's algorithms broke public-key authentication. The site's key-algorithm setting (Advanced SFTP/SCP Settings → Algorithms → Public Key Algorithms) is used for two purposes: choosing the server's own host key, and validating the algorithm of the public keys your users authenticate with. Disable ssh-rsa or DSA to satisfy a vulnerability scan and users authenticating with keys of that type stop working, with Unsupported public key algorithm at INFO level in the log. If you are hardening, migrate users to Ed25519 or ECDSA keys, or keep RSA_sha2_256 and RSA_sha2_512 enabled, before removing plain RSA.

9. The client's address has been auto-banned. CompleteFTP bans an address that accumulates too many failed authentications in a window; the shipped configuration sets both the default site and the admin site to 10 failures within 300 seconds, banned for 1 hour. Two things about this catch people out:

• Each failed method counts separately, not each connection attempt. A single FileZilla connection that tries a key and then a password registers two failures. Five such attempts reach the threshold.
• Once banned, the connection is refused before authentication runs, so the debug log shows only Denied connection on port 22 from 192.168.1.50 due to auto-ban and no session at all. If you see nothing in the log for a connection you know was made, check this first.

Bans are held in memory, are lost on service restart, and can be viewed and lifted in the manager's Monitoring panel. A successful login clears the address immediately. An allow-always IP filter rule exempts an address from banning entirely, which matters when many users share one public address, otherwise one user with a stale password can lock out everyone behind that NAT.

10. SFTP is not enabled for the user, or the server is not what the client reached. If the password is accepted but the log then says has no SSH services enabled, tick SFTP enabled in the user's Allowed Protocols section, or run completeftp user set <user> sftpEnabled=true. If nothing whatsoever appears in the log at Debug level, the client is not reaching this server: check the port (SFTP is 22 by default and the admin site is 14983), check that a different SSH service is not already bound to 22, and test with a known-good client from the server machine itself. A client that connects on the FTP port and speaks FTP will fail in a way that never touches this code path.

11. Domain users have no settings of their own. With the Automatic Windows Users authenticator, domain accounts that have not been added to CompleteFTP explicitly use a hidden template user named defaultWindows. If that template is not enabled for the site, every such user fails. To see it, enable Show system users in the manager's Options menu (the label gains "/folders" in Standard and above and "/sites" in Enterprise MFT). Adding the account explicitly under Add User → Windows User(s) is the alternative, and is what you need anyway if that user requires their own home folder or keys.

12. A gateway authenticator is in the path. In Enterprise MFT a gateway authenticator forwards credentials to another server, and it is tried alongside the local authenticators. Two consequences: an enabled-but-misconfigured gateway can fail a login that would otherwise succeed locally, and a user that exists on both the gateway and the target server will produce confusing results. If the users' public keys live on the remote server, that server must be a CompleteFTP server, have SFTP enabled, and have the password authentication method enabled, even though the user is verified there by key, not password.

13. Permission denied after a successful login is not this problem. Couldn't get handle: Permission denied, or a message of the form No folder-list permission for /, means authentication succeeded and file-system permissions failed. WinSCP in particular tries to change to / on login, and nobody has access to the virtual root by default; set the client's remote directory to the user's home folder, or enable Home folder is root for the user.

If you are on an older release

Modern clients sign with rsa-sha2-256 or rsa-sha2-512 rather than the SHA-1-based ssh-rsa, and OpenSSH has disabled ssh-rsa signatures by default since its version 8.8. A CompleteFTP release that predates support for the algorithm the client is using logs Unknown public key algorithm rsa-sha2-512 at WARN and rejects the key; the fix is to upgrade, as the algorithm name is not recognised at all. Support for user keys by algorithm arrived in: ecdsa-sha2-nistp256/384/521 13.1.0, rsa-sha2-256 and rsa-sha2-512 22.1.1, ssh-ed25519 23.1.0. This is the usual explanation for "it worked for years and stopped when the client team patched their servers, and we changed nothing".

Errors that look similar but are a different problem

These come from the client libraries, connecting out to a third-party server. The server-side settings in this article have no bearing on them:

• EnterpriseDT.Net.Ftp.Ssh.SFTPAuthenticationException and SFTPException: Unknown algorithm none from edtFTPnet/PRO, or SSHFTPKeyException from edtFTPj/PRO, usually a private key that has not been loaded, or a passphrase property that has not been set.
• Anything of the form "the negotiation of X has failed", or "no suitable X could be agreed", means the client and the far server have no algorithm in common for key exchange, encryption, MAC or host key verification. Get a client debug log, compare the two offered lists, and upgrade the client if its list is the shorter one.
• The host signature is invalid or the host key was not accepted, host key verification, not user authentication. The far server's key changed, or the wrong known_hosts entry is in use.

PGP and GnuPG keys cannot be used for SFTP authentication at all, in CompleteFTP or in any other SSH implementation. Could not import key. Failed to recognize public key format is what importing one produces. SSH user keys must be OpenSSH, SECSH/PEM or PuTTY format.

Related

• Product guide, each page tied to a section above: How to set up public key authentication and Set up public-key authentication for a user, the two-places rule and the key import procedure; SFTP/SCP/SSH settings, the site settings and the authentication-method descriptions; How to add a non-Windows user and How to add a Windows user, failure mode 4; How to view system users, failure mode 11; How to configure a gateway authenticator, failure mode 12; IP filtering and auto-banning, failure mode 9; Getting started with FileZilla, failure mode 7; How to view the server log files and How to produce clean log files, reading the debug log; CLI reference, the commands used above.
• Adjacent KB article: How to enable Debug logging in CompleteFTP for troubleshooting, every step in this article assumes you can produce a debug log covering the failure, and it also covers enabling the admin CLI on Windows.
• For the client-side half of this, what to put in FileZilla and WinSCP, and how host key verification works. See Connecting to your SFTP server with FileZilla and WinSCP. For the algorithm settings that failure mode 8 warns about, see Hardening SSH/TLS ciphers to pass a pen test.

Other technical articles

• CompleteFTP service fails to start after an upgrade: how to find the cause and fix it
• CompleteFTP: System.OutOfMemoryException during SFTP, or a service that stops responding
• Does edtFTPnet/PRO support .NET 8? Which assembly to reference for .NET Framework, .NET Core and .NET 5+
• How to disable weak ciphers and encryption algorithms in CompleteFTP
• How to enable Debug logging in CompleteFTP for troubleshooting
• How to export and import CompleteFTP configuration between servers and versions
• IP filtering and whitelisting in CompleteFTP: what it supports and how to configure it
• Passive FTP and FTPS data connection failures in CompleteFTP: login works, the directory listing times out
• Using Active Directory, Entra ID (Azure AD), SAML and LDAP groups to control who can log in to CompleteFTP
• Why SFTP transfers fail with "ConsumeWindowSpace timed out", and how to fix it
• Why an SSL certificate won't import into CompleteFTP, and how to fix it

Download Free Trial