Authentication issues

Authentication fails only after a server has greeted you. A 530 response and an SSH “Authentication failed” line are account problems, not closed ports.

Confirm you are past the greeting

On FTP and FTPS, a real authentication failure looks like a 220 greeting, then USER, then a 530 response such as “Login incorrect.” On SFTP, the log shows a connection and an SSH banner, then “Authentication failed” or “No supported authentication methods available.” If you never see that greeting, go back to connection errors.

For FTPS, AUTH TLS and a 234 reply should appear before USER. A failure at AUTH TLS is encryption, covered in secure file transfers. A 530 after 234 means TLS is already up and the account was rejected. Do not answer that 530 by switching to plain FTP.

FTP and FTPS login

Response: 220 FTP server ready
Command: AUTH TLS
Response: 234 Using authentication type TLS
Command: USER example-account
Command: PASS ****
Response: 530 Login incorrect.

Example only. FileZilla masks the password in the log. Do not put it back when you ask for help.

Retype the password from the operator’s message rather than from memory. A trailing space is enough. If the password was shown once in a welcome mail, generate a new one in the hosting panel instead of forwarding that mail.

Anonymous logon sends the username anonymous and will not open a normal account. Interactive and “Ask for password” are useful on a shared computer because they avoid storing the secret in the site profile. The Account logon type is only for FTP servers that use the ACCT command. Leave it on Normal unless the operator gave you a separate account field.

The username is part of the secret

Operators publish usernames in more than one shape. Some want account, some want [email protected], and some want a panel user that is not the FTP user at all. The SSH user for SFTP is often different again. Copy the username from the place that documents that protocol, and keep the case. SSH usernames are case-sensitive, and many FTP servers are too.

A web-mail address and its mailbox password are not an FTP login unless the host said they are. Guessing combinations produces the lockout in the next section.

Choose the logon type that matches the server

Normal
Username plus password. The usual choice for FTP, explicit FTPS, and password-based SFTP.
Ask for password
FileZilla prompts once per session and does not need the password saved in the site.
Key file
SFTP only. You select the private key. The server must already hold the matching public key.
Interactive
Prompts again for each new connection. Also used when a key has been added under Settings → Connection → SFTP.
Anonymous
Only for servers that offer a public anonymous account.

SFTP passwords and keys

SFTP authentication is SSH authentication. “No supported authentication methods available (server sent: publickey)” means the server will not accept the method you offered. A password can be correct and still fail when the server allows keys only.

For a key, set Logon type to Key file and choose the private key. FileZilla can use a PuTTY .ppk file or an OpenSSH PEM key. Do not select the .pub file. The public half belongs in the server account, usually in authorized_keys, and the operator or your own earlier setup has to place it there. FileZilla does not upload a public key just because you picked a private key.

You can import a key in Edit → Settings → Connection → SFTP with “Add key file…”. FileZilla may convert an OpenSSH key to its own stored form and ask for the key passphrase. That passphrase unlocks the key file. It is not a substitute for the account password, and it is not something to send by email.

If an SSH agent or a list of saved keys offers several identities, the server may disconnect with “Too many authentication failures” before your intended key is tried. Remove keys you are not using for this site and connect again.

Do not paste a private key into chat, into the contact form, or into Server → Enter custom command. A custom command is a place for an FTP verb, not for key material. If a key may have been exposed, stop using it and create a new pair.

Temporary blocks after failed logins

FTP 530 replies and SSH authentication failures are often counted. After a small number, the server or a firewall stops answering, and the next error looks like a timeout or a refusal. That new symptom is a consequence of the bad login, not a new port problem. Wait, confirm the username and method with the operator, and try once. Cycling the Connect button keeps the counter high.

A practical sequence

  1. Find the greeting. If it is missing, fix the connection before you touch the password.
  2. Set the logon type to the method the operator documented: password or key, not both at random.
  3. Replace the username with the published value, including any domain suffix and the original case.
  4. Retype the password, or reselect the private key and its passphrase. Never send either one to Filenilla.
  5. For FTPS, keep “Require explicit FTP over TLS” on unless you were explicitly told to use implicit TLS on its own port.
  6. After a handful of failures, stop and ask whether the address is temporarily blocked.

How to tell it is fixed

FTP and FTPS are past authentication when the log shows 230 and FileZilla moves on to the directory command. SFTP is past authentication when the host key has been verified and the remote pane is requested without an authentication error. A failure on MLSD, LIST, or the SFTP directory read is the next stage, not another password.

Common mistakes

  • Using the panel password, or an email password, as the FTP password.
  • Selecting the public key file, or a key that was never installed for this user.
  • Leaving Logon type on Anonymous or Account.
  • Treating a TLS handshake error as a 530 and revealing the password by falling back to plain FTP.
  • Repeating a failing login until the address is blocked, then diagnosing the block as a bad host.