SFTP Connection Errors: Why They Happen and How to Fix Each One

"Host key verification failed." "Permission denied (publickey)." "Connection refused." "Connection timed out." If your SFTP client is throwing one of these, the error message usually names the layer that broke — server identity, authentication, reachability, or the network path itself. This guide is tool-agnostic: it explains what each message really means, where the problem most likely lives, and how to fix it. (Stuck on plain FTP instead? See the FTP connection errors guide.)

Connect Now — access your SFTP server

Stuck right now? 3 quick checks

Before you dig into any single error, run these three checks — they clear most failures in under a minute.

Host & port: 22 or your custom SSH port

Verify the hostname and port you're typing. SFTP runs inside SSH, so the port is 22 by default — not 21 (that's plain FTP). Some hosts run SSH on a custom port (e.g. 2200 or 2222) and publish it in their welcome email or control panel. Connecting to the right host with the wrong port — or selecting SFTP when the account is FTP-only — produces a refused or timed-out error every time. Copy the exact host and port from your provider rather than typing from memory.

Authentication: password vs SSH key

Many SFTP servers accept only SSH-key authentication and reject passwords outright — that produces "permission denied (publickey)," not a password error. Check which method your host expects: documentation, the control panel, or the welcome email usually says "password" or "SSH key." If you're not sure, the section on publickey errors below walks through both sides.

Retry from another network

If you can, test from a second network — a phone on mobile data, a different Wi-Fi, or a colleague's connection. If the same credentials and server work elsewhere, the problem is almost certainly a local firewall, a router rule, or an upstream network block on the network you're sitting on.

Host key verification failed

This is the most common SFTP-specific error, and it is also the one people most often "fix" the wrong way — by blindly accepting whatever the client offers. Let's be precise about what it means, because the fix depends on which case you're in.

What a host key is

Every SSH server has a permanent identity: a cryptographic host key it presents when a client connects. Your client is supposed to remember that key so that the next time you connect, it can check the server is still the same machine — not an impostor sitting in the middle of the connection (a man-in-the-middle attack). OpenSSH stores these keys in your ~/.ssh/known_hosts file; desktop SFTP clients keep their own equivalent store.

What "verification failed" actually means

The message appears in one of two situations, and the correct response is different for each:

No record yet (first connect). Your client has never seen this host, so it has nothing to compare against. The client shows you the fingerprint — often with a prompt to accept it — and this is normal on the very first connection. What you should do: compare the fingerprint you see against the value your hosting provider publishes (look in the control panel or documentation) before accepting, or check it yourself with ssh-keyscan -t ed25519 yourhost.example.com from a trusted network.
The key changed. Your client has a stored key for this host, and the server just presented a different one. Something changed on the server side — a legitimate rebuild/reinstall (common after OS reinstalls or instance migrations) or an attacker intercepting your connection. Never accept a changed key blindly: verify the new fingerprint independently first, exactly like a first connect, and if you can't verify it, treat the connection as suspicious.

What FilePort Pro does (trust on first use)

FilePort Pro uses trust-on-first-use (TOFU), the same model as OpenSSH: the first time you connect to a host, the app records the server's SHA256 host-key fingerprint in your browser, keyed by host and port, and displays it to you so you can check it against the value your host publishes. If a server's key later changes, FilePort refuses to connect until you explicitly confirm the change — the opposite of silently accepting an impostor. The fingerprint is not a secret, it's the only thing stored by default, and the exact mechanics are on the security page.

First connect vs changed key, in one line

First connect: verify the fingerprint, then trust it going forward. Changed key: verify the new fingerprint independently before accepting anything — a rebuilt server is plausible, a silent acceptance is how MITM attacks win.

Permission denied (publickey)

This message means the authentication method is the problem: the server wants an SSH key, and you're offering a password — or you're offering a key and the server rejected it.

The server wants key auth, not a password

Many servers (cloud VPSes especially) are configured with PasswordAuthentication no in sshd_config, so the only accepted method is public-key authentication. When you type a password, the server answers "permission denied (publickey)" — it's not saying your password is wrong, it's saying passwords aren't the method it accepts.

Where your key lives on desktop clients

Desktop clients (OpenSSH, FileZilla, WinSCP, Cyberduck) use a key pair: a private key file on your computer (often ~/.ssh/id_ed25519 or id_rsa) and a public key installed in the server's ~/.ssh/authorized_keys. The client presents the private key during the handshake and also consults its host-key store (known_hosts on OpenSSH) — that's the same trust-on-first-use model described above.

How to fix it

If you own the server and want password logins: set PasswordAuthentication yes in sshd_config and restart sshd. (Only do this on a server you control, and keep key auth — disabling passwords entirely is the more secure default.)
If you don't control the server: use a desktop client with your key, or ask the host to add a password method. A browser client like FilePort Pro sends the credentials you type; it can't conjure a key you haven't given it — so for key-only servers, a local client with your key files is the route.

Connection refused

Refused means someone reached the server and was told "no" — a packet came back resetting the connection. Something is listening and declining, or a firewall is actively rejecting. The causes are usually concrete.

Wrong port — 22 vs 21

Confirm you're connecting to 22 (the SSH/SFTP port) and not 21 (plain FTP). If the host runs SSH on a custom port, use that exact number. A wrong port is the single most common cause of refusal on SFTP setups.

SSH/SFTP service disabled on the server

If the SSH daemon isn't running, port 22 answers with a refusal. On shared hosting the service runs on the host's side — check with the provider (many plans are FTP-only, or SSH must be enabled in the panel first). On your own VPS you can check (e.g. systemctl status sshd or ss -ltn) and start it. cPanel/WHM users: SSH/SFTP access is toggled per-user under Account Functions → Manage Shell Access — see our cPanel FTP guide for where these settings live.

Firewall or antivirus on your computer

Desktop clients are sometimes blocked by the machine's own firewall or antivirus — Windows Defender, third-party suites, and corporate endpoint products all do this. Add an exception for the client executable, or test with a different machine to rule it out.

The server is blocking your IP

Servers with geo/IP allowlists reject connections from outside the allowed range — often as a refusal. If the same client works from another network or a VPN, your IP is the problem. On cloud VPSes, the security group is the usual culprit: AWS blocks inbound entirely until you add a rule. Our AWS EC2 SFTP guide shows how to open TCP 22 in the security group.

Connection timed out

Timeout means your request went out and nothing came back — packets are being dropped, not rejected. Where "refused" is a door slammed, "timed out" is a door that was never reached. The fix depends on where the silence happens.

Firewall dropping traffic — not refusing it

Firewalls are often configured to silently drop rather than reject. The effect is a timeout. If a host worked before and times out now, check whether its firewall rules (or your cloud provider's security group) changed — for example, whether TCP port 22 is open from your IP range.

Server down, or DNS points at the wrong IP

A powered-off or crashed server never answers. DNS can also be stale or wrong, sending you to an IP where nothing listens. Run a port check (next section) to see whether the host resolves and whether the port answers at all.

Outbound port 22 blocked by your network

ISPs, corporate networks, and school networks sometimes block outbound SSH ports, and some destinations block port 22 from datacenter or residential ranges. This is the classic case where the same credentials work from a phone hotspot. Test from another network before blaming the server.

Home-LAN server without port forwarding

An SFTP server on your home network is reachable from that network but invisible from the internet unless the router has a port-forward rule for TCP 22 (or your custom port) pointing at the server. Without it, outside connections time out — and a browser-based client can't reach it either (see the FAQ below): relayed connections need a publicly reachable host.

Other authentication failures at a glance

Error	What it means	What to do
No supported authentication methods	The server offers authentication methods your client didn't send — typically it accepts only key auth (or only password auth) and your client tried the other.	Match the method to what the server accepts: supply an SSH key for key-only servers, or a password where password auth is enabled.
Password authentication failed	The server accepted password logins but rejected the specific password (or username) you sent.	Re-check the password carefully — case matters and a trailing space breaks it — and confirm the SFTP user exists and is enabled for SSH (cPanel: Manage Shell Access).
Too many authentication failures	The client sent more auth attempts than the server permits (often because it keeps trying keys that fail before trying the password).	Tell the client which key to use explicitly, or remove stale keys from its list so the correct credential is tried early.
Connection closed by server	The server terminated the connection mid-handshake — frequently a rate limit or an automated ban after repeated failed attempts, or a fail2ban-style block on your IP.	Wait out the ban window (usually minutes), check with the host for a permanent IP block, and avoid hammering repeated failed logins from the same IP.

Narrow it down: port check, then a connection test

Instead of guessing, run the diagnosis in two steps. Where it fails tells you which fix applies.

Check the port. Use the FTP Port Checker — it probes TCP from our servers to your host:port and reports open, closed, filtered (timeout), or unreachable. A filtered result points at a firewall dropping packets; closed means the service is off or rejecting; unreachable means DNS or routing is wrong. It can probe port 22 or any custom SSH port.
Test the login. If the port is open but the handshake still fails, use the SFTP Connection Tester with your own credentials. To be exact about what it proves: a successful test does confirm the server accepted your username and password and completed the SSH/SFTP handshake — after which it stops immediately. It does not prove you can read, write, or list files there; those permissions are separate and are not checked.

That gives you the four-way split: DNS (host doesn't resolve → unreachable), TCP (port closed/filtered → service or firewall), handshake (port open, key verification fails → host key changed or unknown), and auth (handshake succeeds but login is rejected → credentials or key-vs-password method).

Fixed? Connect in your browser — SFTP with host-key verification

Once the server side is healthy, connect without installing a client. FilePort Pro's SFTP client runs in your browser and connects over SSH with the same host-key verification described above — on first connect it shows you the server's SHA256 fingerprint, and it refuses to connect if a key ever changes. Credentials are held in memory for the active session only (never stored, never logged), and the session ends when you disconnect or after about 15 minutes of inactivity.

Some honest limits, so you're not surprised later:

The relay can only reach publicly reachable hosts. FilePort's servers make the connection on your behalf, so a host that's only reachable on your LAN — or one that blocks our server's IP range — can't be reached from the browser.
SFTP-over-SSH is the right choice when it's offered. Everything inside SSH is encrypted: your username, your password, and your files. Plain FTP sends all of it in cleartext — if your host offers SFTP, prefer it; FilePort supports both.
Key-only servers still need a key. If the server accepts only SSH-key authentication, the browser client can only send the credentials you type — you'd need a desktop client with your key files, per the publickey section above.

Ready when the server is: Connect Now — transfer files from your browser

Frequently asked questions

What does "Host key verification failed" mean?

The server's identity check failed. Either you have no record of this host yet (first connect), or the host key changed since your client last saw it. Check the current fingerprint against your host's published value (control panel or docs) via ssh-keyscan, and never accept a changed key blindly — it can mean a legitimate server rebuild or a man-in-the-middle attack.

Is it safe to accept the new host key?

Only after you have verified the new fingerprint independently — from your hosting provider's published value, or by running ssh-keyscan yourself from a trusted network. A changed key can mean a legitimate server rebuild, but it can also mean the server was swapped by an attacker. Never accept blindly just to make the error go away.

Why does FilePort Pro show me an SFTP fingerprint?

FilePort Pro uses trust-on-first-use (TOFU): the first time you connect to a host it records the server's SHA256 host-key fingerprint in your browser and displays it so you can compare it with the value your host publishes. If the key later changes, the app refuses to connect until you confirm the change. Details are on the security page.

What's the difference between "permission denied (publickey)" and a password error?

"Permission denied (publickey)" means the server rejected your SSH key — or refused password login entirely because it is configured for key-only authentication. A plain "password authentication failed" means the server accepted password logins but rejected the password. For key-only hosts, enable password auth (PasswordAuthentication yes in sshd_config), or use a desktop client with your key file.

What's the difference between "connection refused" and "timed out"?

Refused means the server (or a firewall) actively rejected the connection — nothing is listening on that port, or something is deliberately resetting it. Timed out means no response at all: packets are being dropped by a firewall, the server is down, or DNS points at the wrong IP.

Can FilePort Pro reach my SFTP server on my LAN?

No. FilePort relays your connection through a cloud server, so it can only reach hosts that are publicly reachable on the internet. A server on your home LAN is invisible from outside unless the router port-forwards TCP 22 to it, and even then the relay needs a public address to connect to.

More help

Tools and guides that pair with this one:

FTP Port Checker — is the port even reachable?
SFTP Connection Tester — test the handshake with your credentials.
FTP connection errors — the plain-FTP sibling of this guide (530, passive mode, data connections).
AWS EC2 SFTP — opening TCP 22 in a security group.
cPanel FTP — where SSH access, SFTP users, and passwords live.
Web SFTP client — connect from the browser, no install.
Security — exactly how FilePort Pro handles credentials, sessions, and host keys.
FileZilla alternatives — free desktop and no-install options.

If a fix ends in "ask your host," that's not a cop-out — stopped services, key-only policies, security groups, and IP blocks are all server-side by design. No client setting can reach them.