Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
SSH reports connection refused when your client reaches the VPS but the requested TCP port actively rejects the connection. In practice, either sshd is stopped or misconfigured, SSH is listening on a different port, or a local or provider firewall is rejecting that port. Use the VPS provider’s browser, serial, VNC, or rescue console first, then check the daemon, validate its configuration, confirm the listening port, and inspect both firewall layers. This sequence restores access without guessing or repeatedly rebooting the server.
What “connection refused” tells you
A refused connection is different from a timeout. The TCP request reached the server’s address and received an explicit rejection. That normally means no process accepted the requested port, or a firewall rule returned a reject response. A timeout usually means packets are being dropped somewhere, the machine is offline, or the address is not reachable.
Free tools Windows power users keep installed
One-click scans. No signup required.
The message does not identify which component is at fault. The VPS may still be booting, sshd may have stopped after a configuration change, the client may be using port 22 while the server listens elsewhere, or a host firewall or cloud security rule may reject the connection. Start with the checks that require no network access to the affected SSH service.
Start with out-of-band access
Do not depend on SSH to repair SSH. Sign in to your VPS provider and open its browser console, serial console, VNC console, or rescue environment. These channels connect to the virtual machine through the provider’s control plane and remain available when sshd is down.
#1 Best Overall
Choose the appropriate console
- Browser or serial console: best for a normally booted system whose network SSH service is broken.
- VNC console: useful when you need to see boot messages or a login prompt and a serial device is not configured.
- Rescue instance or recovery environment: use when the guest will not boot, the root filesystem is damaged, or you cannot obtain a local login.
Google Cloud, AWS, and DigitalOcean document console or rescue paths for unavailable SSH. Provider labels differ, but the objective is the same: obtain a root or administrative shell without traversing the failing SSH port.
Confirm that the VPS is running and has finished booting
In the provider panel, verify that the instance is powered on, assigned the expected public address, and not stuck in a provisioning or reboot state. A VM that is still booting can temporarily refuse connections. If the console shows a kernel panic, filesystem check, emergency mode, or repeated reboot, fix that condition before troubleshooting sshd.
Once you have a shell, check the basic operating state:
uptime
systemctl is-system-running
systemctl --failedsystemctl --failed highlights failed units that may explain why networking or the SSH service never started. Also check whether the root filesystem is full; a full filesystem can prevent services from writing logs, creating runtime files, or completing startup.
df -h
sudo du -xhd1 /var 2>/dev/null | sort -hFree space carefully by removing known-safe logs, caches, or old kernels according to your distribution’s procedures. Do not delete unknown files from /var/lib or a database directory simply to make the percentage drop.
Check whether the SSH daemon is running
On most Linux distributions the service unit is named sshd; on some it is named ssh. Query the first name, then the second if necessary.
sudo systemctl status sshd
sudo journalctl -u sshd --no-pager -n 50sudo systemctl status ssh
sudo journalctl -u ssh --no-pager -n 50Look for messages such as “failed,” “address already in use,” “bad configuration option,” missing host keys, permission errors, or a service that was stopped by an administrator. The journal command displays the most recent 50 entries; increase the number or remove -n 50 when the failure occurred earlier.
Start or restart the service only after checking the error
If the unit is inactive and the journal does not show a configuration error, start it:
sudo systemctl start sshdUse sudo systemctl start ssh when that is the unit name. If the service starts, test SSH from another terminal before making additional changes. If it fails, do not keep restarting it; validate the configuration first.
Validate the SSH configuration before restarting
A single typo in /etc/ssh/sshd_config or an included file can prevent the daemon from starting. The built-in test parses the configuration without launching a listener:
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →sudo sshd -tNo output means the syntax passed. Any output is an actionable error: correct the referenced line or file, then run sshd -t again. Modern distributions commonly load snippets from an sshd_config.d directory, so inspect included files as well as the main file.
sudo grep -RInE '^(Port|ListenAddress|Include|PermitRootLogin|PasswordAuthentication)' /etc/ssh/sshd_config /etc/ssh/sshd_config.d 2>/dev/nullDo not blindly overwrite the configuration with a default file. Preserve settings you intentionally use, such as key-only authentication, restricted users, or a nonstandard port. After the test succeeds, restart the correct unit:
sudo systemctl restart sshdIf your distribution uses ssh, restart that unit instead. Immediately inspect the status and journal again so you can distinguish a successful restart from a service that exited a few seconds later.
Find the port on which sshd is actually listening
A client that probes port 22 will be refused if the daemon was changed to another port. Ask the daemon for its effective configuration rather than relying only on what you remember editing:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
sudo sshd -T | grep '^port'The output may list more than one port. Confirm that a process is listening on the expected TCP socket:
sudo ss -tlnp | grep ':22'Replace 22 with each configured port. A listener shown as 0.0.0.0:PORT or [::]:PORT accepts connections on all interfaces; a listener bound only to a private address will not accept connections arriving on the public interface. If no matching line appears, sshd is not listening there even if systemd reports the unit as active.
Match the client command to the server
Use the server’s actual address, account name, identity file, and port:
ssh -p 2222 user@SERVER_IPFor a non-default key, specify it explicitly:
ssh -i ~/.ssh/id_ed25519 -p 2222 user@SERVER_IPOn the client, run verbose mode when you need to see which address and port are being attempted:
ssh -vvv -p 2222 user@SERVER_IPVerbose output is useful for confirming that DNS is resolving to the intended VPS and that the client is not silently using an old configuration entry from ~/.ssh/config.
Check both firewall layers
A VPS commonly has two independent filtering layers: rules inside the guest and a provider firewall or security group outside it. Either one can reject the configured SSH port, and changing only one layer will not restore access.
Inspect the firewall inside Linux
Use the command set that matches your distribution. Read the current policy before adding a rule:
sudo ufw status verbosesudo firewall-cmd --state
sudo firewall-cmd --list-allsudo nft list rulesetsudo iptables -SPermit TCP access to the actual SSH port from the intended source address. For UFW, a typical restricted rule is:
sudo ufw allow from YOUR_PUBLIC_IP to any port 2222 proto tcpFor firewalld, add the port to the active zone and reload:
sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --reloadUse your configured port instead of 2222. If you are locked out and need a temporary diagnostic rule, restrict it to your own public IP and remove it after testing. Opening SSH to every source address increases exposure and does not fix a daemon that is not listening.
Rank #4
Inspect the provider firewall or security group
In the VPS control panel, review cloud firewall, security-group, network ACL, or inbound-rule settings attached to the instance and its network interface. Allow inbound TCP on the configured port from the address range you actually use. Check both IPv4 and IPv6 rules if the client resolves an IPv6 address.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallOutdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchProvider rules can be changed independently of the guest OS. A local UFW rule may be correct while the provider still rejects the port; conversely, an open provider rule cannot compensate for a local firewall reject.
Test the port from the client
After correcting the service, port, and firewalls, test basic TCP reachability before diagnosing authentication:
nc -vz SERVER_IP 2222A successful result confirms that something accepts the TCP connection. It does not prove that your username, key, or password is valid. If nc still reports refusal, return to the listener and firewall checks. If it times out, investigate the VPS state, address, routing, and provider filtering instead of treating it as the same failure.
Then retry SSH with the exact command that matches the effective configuration:
Recommended Free Tools
ssh -p 2222 user@SERVER_IPInvestigate failures beyond sshd
Missing or invalid host keys
The daemon normally needs host keys under /etc/ssh. If the files are missing after a rebuild or filesystem repair, regenerate them from the console:
sudo ssh-keygen -ACheck the journal after regeneration and restart the service. Do not copy a host key from an unrelated machine; clients use host keys to detect that a server identity changed.
Permissions and ownership
SSH can refuse to start or reject authentication when key files or directories are writable by the wrong users. Verify ownership and modes on the server’s /etc/ssh files and on each account’s ~/.ssh directory. On the client, private keys should normally be readable only by their owner:
Best Value
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519These client-side permissions usually cause a key-permission warning rather than “connection refused,” so fix them after the TCP listener is working.
Port conflicts and address binding
The journal may report “address already in use” when another process occupies the configured port. Identify the process:
sudo ss -tlnp | grep ':2222'Stop or reconfigure the conflicting service, or choose an unused SSH port and update both firewall layers and the client command. If ListenAddress limits sshd to an address that no longer exists, remove the stale binding or replace it with the VPS interface address, then rerun sshd -t.
Kernel, boot, and guest-agent problems
A kernel regression after an upgrade, a panic, or a failed network initialization can leave the VPS reachable only through its console. Review boot output and the system journal, and use the provider’s documented recovery or previous-kernel procedure. A stopped guest agent can also prevent console or network configuration actions from completing, even when the operating system appears partly alive.
Intrusion-monitoring software
Tools that automatically ban source addresses can reject your connection after repeated failed logins. Inspect their logs and unban your address through the console. Correct the underlying authentication problem and keep rate-limiting enabled; disabling protection permanently is not a repair.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Provider-specific checks
| Provider documentation focus | Checks that matter for a refused connection |
|---|---|
| Google Cloud | Confirm the VM is still booting or not stopped, check custom SSH ports and firewall rules, inspect for a kernel panic after an upgrade, and use the serial console when sshd is stopped or misconfigured. |
| AWS | Use systemctl, journalctl, sshd -t, and ss; verify security-group rules, host keys, and port conflicts. AWS describes refusal as the host being reached while no service accepts the SSH port or a reject rule responds. |
| Azure | Verify that sshd listens on TCP 22 or your custom port, then check the VM’s local firewall, network-security-group rules, and intrusion-monitoring software. |
| Vultr | Review the provider firewall and use the web console to diagnose the guest without relying on SSH. |
| DigitalOcean | Use the console or recovery environment, check cloud firewall rules, and decide whether data recovery for redeployment is safer than prolonged troubleshooting when boot or filesystem health is uncertain. |
Distribution names and panel labels vary, but these checks map to the same layers: machine state, daemon, effective port, guest firewall, provider firewall, and underlying filesystem or boot health.
Repair the server or redeploy it?
Redeployment is not automatically faster or safer. Decide after you have console access and know whether the data and operating system are trustworthy.
| Decision factor | Continue repair | Snapshot and redeploy |
|---|---|---|
| Out-of-band access | Available and provides a usable shell or recovery environment. | Unavailable, unreliable, or unable to reach the disk. |
| Data-preservation requirement | Configuration and application state must remain in place and can be backed up. | Required data can be copied or captured in a verified snapshot first. |
| Filesystem and boot health | Logs show a contained service, port, or firewall error and the OS is otherwise healthy. | Kernel panic, repeated boot failure, corruption, or unexplained system instability persists. |
| Time to restore service | A configuration correction can be tested without changing the machine identity. | A known-good image and automation can produce a clean replacement faster. |
| Provider capabilities | Console, snapshots, and rescue instances are available for controlled repair. | Snapshot or rescue support makes data capture and rollback practical. |
Before redeploying, take a provider snapshot when possible, copy application data and configuration, record the intended SSH port and firewall rules, and verify that backups are readable. If the provider explicitly recommends recovery for redeployment, treat that as a risk decision rather than a command to erase the original instance immediately. A VPS with browser, serial, or rescue-console access is easier to recover from future SSH failures than one that offers only network login.
Prevent another lockout
- Keep one administrative access path through the provider console and test it before changing SSH.
- Make one SSH configuration change at a time, run
sudo sshd -t, and keep an existing session open while testing a new session. - Document the effective port,
ListenAddress, allowed users, identity files, and both firewall layers. - Permit the new port in the provider firewall and guest firewall before removing the old rule.
- Maintain tested snapshots or backups before kernel, network, and SSH changes.
- Monitor disk usage and failed systemd units so a full filesystem or boot failure is visible before it becomes an outage.
- Keep host keys and configuration files in a protected backup, but do not reuse host keys across unrelated machines.
Quick recovery checklist
- Open the provider’s browser, serial, VNC, or rescue console.
- Confirm the VPS is powered on and has completed booting.
- Run
systemctl status sshdand inspectjournalctl -u sshd --no-pager -n 50; try thesshunit name if needed. - Run
sudo sshd -tand fix every reported syntax or included-file error. - Run
sudo sshd -T | grep '^port'and verify listeners withsudo ss -tlnp. - Check UFW, firewalld, nftables, or iptables inside the VPS and the provider security group or cloud firewall outside it.
- Retest with
nc -vz SERVER_IP PORT, then usessh -p PORT user@SERVER_IP. - If the daemon still cannot start, check host keys, permissions, disk space, boot and kernel errors, guest-agent status, and intrusion-monitoring bans.
- Snapshot or copy data before choosing a rescue-based redeployment.
The practical diagnosis is usually narrow: a refused SSH connection means the host answered but the requested endpoint did not accept the connection. Console access lets you identify whether the missing listener, wrong port, local firewall, provider rule, or deeper system failure is responsible, and it gives you a recovery path even when the network service itself is unavailable.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
