A plain SFTP connection refused error usually does not mean SFTP is broken, it means the SSH server never accepted the TCP connection on port 22. That makes the problem highly testable: if port 22 is listening and reachable, you know the failure sits somewhere else.

You need to fix this fast because the same error can hide very different causes, from an SSH service not running to a blocked port 22 firewall rule or a bad hostname. In the next sections, you will check the SSH daemon, test firewall access, and verify the target server and SSH config with commands you can run right away.

Why does SFTP say 'Connection refused' when the real problem is usually SSH?

SFTP rides on SSH

SFTP uses the SSH transport, so the failure often happens before the file transfer layer even starts. If the server rejects the TCP connection on port 22, your SFTP client has nothing to build on.

On systemd-based Linux servers, SSH commonly uses socket activation, and ssh.socket listens on port 22 by default [1]. That means a clean-looking SFTP error can still point to SSH daemon startup, socket activation, or a port change, not the SFTP subsystem itself. If the connection starts but fails on the server identity check, see Host Key Verification Failed.

What the error really means

“Connection refused” usually means you reached the host, but nothing accepted the connection on that port. That is different from a timeout, which usually suggests a network path problem.

A quick example helps. If sftp user@server fails immediately, but nc -vz server 22 also says refused, you are looking at SSH availability or listening state, not a broken client. If you get past this stage but hit access errors, see Permission Denied fixes. openSFTP helps here because it surfaces these failures clearly, so you can separate client noise from server-side problems faster.

Where to look first

Focus on three layers:

  • Is sshd actually running?
  • Is port 22 reachable through the firewall?
  • Are you connecting to the right host and port?

That sequence saves time because each test narrows the fault domain. Next, you will confirm whether the SSH daemon is up and listening where SFTP expects it.

Is the SSH daemon actually running and listening on port 22?

Check the service first

Start with the server itself. On a systemd host, run systemctl status ssh on Debian or Ubuntu, or systemctl status sshd on RHEL and Fedora. An Active: running status tells you the SSH server is up and ready to accept connections [4].

If the service is stopped, start it right away with systemctl start sshd or systemctl start ssh. If it keeps failing, the issue is deeper than SFTP, because the SSH server software must be installed and running for any SFTP login to work [3]. That gives you a concrete failure point instead of guessing.

Confirm port 22 is listening

A running service is not enough. You also need to see a listener on port 22. Use ss -tlnp | grep :22 or netstat -tlnp | grep :22.

A healthy result looks like 0.0.0.0:22 ... LISTEN ... sshd, which means sshd is waiting for incoming connections [5].

If you do not see port 22 in LISTEN, SSH may be misconfigured or failing during startup [6]. On systemd systems, SSH often uses socket activation, and ssh.socket listens on port 22 by default [1]. If you changed the port or address, update the SSH config, then run systemctl daemon-reload and restart SSH [2].

A quick example

If systemctl status sshd shows inactive, and ss -tlnp shows nothing on :22, your SFTP client will get “Connection refused” every time. Fix the service first. Once SSH is active and listening, you can move on to the network layer, because a live daemon still cannot help you if a firewall blocks the packet before it reaches port 22.

Could a firewall or security group be blocking the connection?

Check the host firewall

If sshd is running and listening on port 22, the next suspect is the firewall on the server itself. A local rule can still drop or deny SSH traffic, and that looks like an immediate refusal from the client side [2].

On a typical Ubuntu server, systemctl status ssh and ss -tlnp | grep :22 can reveal the issue in under 30 seconds: if ssh.service is inactive or nothing is listening on 0.0.0.0:22, SFTP will fail immediately with "Connection refused" before authentication even starts. If ufw status shows port 22 blocked, ufw allow ssh often fixes it instantly. That is the fastest path through most Connection refused troubleshooting cases.

Verify UFW or iptables

Run ufw status verbose and look for an allow rule on 22/tcp or SSH. If you see Status: active but no SSH allowance, add it with ufw allow ssh, then retry your SFTP client.

If you use iptables or firewalld instead of UFW, check for a rule that drops or rejects TCP port 22. Ask Ubuntu documents exactly this pattern, where sshd is active but a firewall rule still blocks access to tcp dpt:ssh [9]. The fix is not in your client, it is in the server policy.

Look beyond the box

Host firewalls are not the only gate. If the server sits in a cloud network, security groups, routing tables, or intermediate firewalls can block port 22 even when the machine itself looks healthy [8]. AWS Transfer Family calls out security groups that do not allow traffic on port 22 between subnets and the target SFTP server [10].

A simple test helps here. If nc -vz your-host 22 works from one network but fails from another, the service is probably fine and the path is not. Once you know the connection reaches the right machine, you can move on to the target itself, because a blocked route and a wrong destination can produce the same error message.

Is the hostname, IP address, or SSH config pointing you at the wrong server?

Confirm the target resolves

A wrong hostname can look exactly like a SFTP connection refused problem. Start by checking what your machine actually resolves with nslookup your-host, dig your-host, or getent hosts your-host.

If the name points to the wrong address, fix DNS or your /etc/hosts entry first. AWS notes that an incorrect IP address or DNS name in the configuration can trigger connectivity errors, and Built In also calls out wrong host details as a common cause of “Connection Refused” [11][12].

Check IPv4 and IPv6

Sometimes the hostname resolves correctly, but only over the wrong protocol family. A GitHub report showed SSH and SFTP failing on a hostname that resolved to IPv6, while the same server worked immediately over its IPv4 address [13].

Test both paths directly. Run ssh -4 user@host and ssh -6 user@host if your client and server support them. If one works and the other fails, you have found the mismatch, and you can adjust DNS, client preference, or server reachability.

Inspect SSH config

Your ~/.ssh/config file can quietly override the host, user, or port. Look for entries like Host prod, Hostname, Port, or ProxyJump, because one bad alias can send SFTP to the wrong place.

This matters a lot when you expect port 22 but your config points at a custom port. Compare ssh -G your-host | grep -E 'hostname|port|user' with what you think you set. Then test with a direct SSH login, ssh -vvv user@host, and compare that result with SFTP.

If SSH reaches the server but SFTP still fails, you know the problem sits in the client path or subsystem, not the network.

Once You Have The Right Server

Once you have the right server and the right port, you can stop guessing and focus on the actual failure mode.

SFTP connection refused usually means SSH failed first

A plain SFTP connection refused error is usually not an SFTP problem at all. You checked the real failure points instead: whether SSH is running, whether port 22 is listening, whether a firewall or security group blocks it, and whether your hostname, IP, or SSH config points you at the wrong server.

That makes the error falsifiable, just like the hook said. If sshd is up, ss -tlnp | grep :22 shows a listener, and nc -vz host 22 reaches the server, then the problem is not random and not mysterious. You can isolate it.

Your next step is simple: run systemctl status sshd or systemctl status ssh, then test ss -tlnp | grep :22 on the server and nc -vz your-host 22 from your client.

Sources

  1. Ask Ubuntu, "SSH socket activation listens on port 22 by default and port or address changes require daemon-reload and restart" (2025-04-24) [https://askubuntu.com/questions/1533119/ssh-connection-refused]
  2. Ask Ubuntu, "SSH socket activation port or address changes require editing sshd configuration and restarting SSH" (2025-04-24) [https://askubuntu.com/questions/1533119/ssh-connection-refused]
  3. RunCloud, "SSH server software must be installed and running for SFTP or SSH connections" (2024-01-01) [https://runcloud.io/blog/fix-ssh-connection-refused]
  4. RunCloud, "systemctl status ssh can confirm SSH is active and running" (2024-01-01) [https://runcloud.io/blog/fix-ssh-connection-refused]
  5. Ask Ubuntu, "netstat LISTEN on port 22 shows sshd is accepting SSH connections" (2024-01-01) [https://askubuntu.com/questions/739164/ssh-connection-refused]
  6. Ask Ubuntu, "No LISTEN on port 22 may indicate SSH is misconfigured or failing to start" (2024-01-01) [https://askubuntu.com/questions/739164/ssh-connection-refused]
  7. OpenBSD Manual Pages, "sshd_config defines sftp-server and internal-sftp as SFTP server options" (2024-01-01) [http://man.openbsd.org/sshd_config]
  8. OneUptime, "If sshd is running and port 22 is allowed, remaining issues are likely network-level" (2026-03-04) [https://oneuptime.com/blog/post/2026-03-04-fix-connection-refused-port-22-ssh-rhel/view]
  9. Ask Ubuntu, "Firewall rules can still block tcp dpt:ssh even when sshd is running" (2024-01-01) [https://askubuntu.com/questions/218344/why-am-i-getting-a-port-22-connection-refused-error]
  10. AWS, "Security groups may need to allow port 22 for SFTP connectivity" (2024-01-01) [https://docs.aws.amazon.com/transfer/latest/userguide/sftp-connectivity-issues.html]
  11. AWS, "Incorrect IP address or DNS name can cause a Resource Configuration error" (2024-01-01) [https://docs.aws.amazon.com/transfer/latest/userguide/sftp-connectivity-issues.html]
  12. Built In, "Wrong IP address or hostname can cause Connection Refused" (2024-01-01) [https://builtin.com/articles/ssh-connection-refused]
  13. GitHub, "Hostname resolved to IPv6 failed for SSH and SFTP while IPv4 succeeded" (2024-01-01) [https://github.com/isontheline/pro.webssh.net/issues/1268]

Frequently Asked Questions

What is the fastest first test for an SFTP connection refused error?

Start by checking whether SSH is listening on port 22 with ss -tlnp | grep :22 on the server. Then test reachability from your client with nc -vz host 22 to see if the issue is local, network, or server-side.

Why does SFTP connection refused usually point to SSH instead of SFTP itself?

SFTP runs over SSH, so the connection must succeed at the SSH layer before file transfer can begin. If the TCP connection on port 22 is refused, the SFTP subsystem never gets a chance to start.

How can I tell whether the problem is a firewall or a stopped SSH service?

If systemctl status ssh or sshd shows the service is inactive, fix that first. If SSH is running and listening but nc -vz host 22 still fails, the firewall or security group is the more likely cause.

What should I check if the hostname works but SFTP still fails?

Verify that the hostname resolves to the expected IP and that your SSH config is not overriding the host, user, or port. Also test both IPv4 and IPv6, since one family may work while the other is blocked or misconfigured.

Can a wrong port number cause SFTP connection refused?

Yes. If your SSH server is not listening on the port your client uses, the connection will be refused even if the server is otherwise healthy. Check ssh -G host or your ~/.ssh/config for a custom Port setting.

What should I do next if SSH is running and port 22 is open?

Run a verbose SSH test with ssh -vvv user@host to see where the handshake fails. If SSH connects successfully, the issue is likely in the SFTP client, account permissions, or the remote SSH subsystem configuration.