Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errors“Connection refused” means your device reached the VPS, but nothing accepted the TCP connection on the port you tried, or a firewall actively rejected it. It is different from a timeout, where no response comes back. Recover access through the provider’s browser, serial, VNC, or rescue console; check whether sshd is running; validate its configuration; confirm the listening port; then inspect both the VPS firewall and the provider’s cloud firewall. Do not keep restarting blindly: an invalid configuration can prevent the daemon from starting again.
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
The safest order is: obtain out-of-band access, inspect the service and logs, run sshd -t, verify the actual port, check both firewall layers, investigate boot or filesystem problems, retest with the correct user/key/address, and only then decide whether repair or redeployment is safer.
As an Amazon Associate I earn from qualifying purchases.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →What “connection refused” tells you
A TCP connection has several possible outcomes. With a refusal, packets reached the server’s address and the server (or a device in front of it) returned a rejection because no process was accepting that port or a reject rule answered. The VPS may be powered on and reachable even though the SSH service is unusable.
| Client symptom | What it usually means | First investigation |
|---|---|---|
Connection refused |
The host responded, but no service accepted the requested TCP endpoint, or a reject rule sent an explicit refusal. | Check VPS state, sshd, configured port, and local/cloud firewalls. |
Connection timed out |
No response reached the client. Routing, a dropped firewall rule, an offline instance, or an incorrect address is more likely. | Check the instance state, address, routes, and rules that silently drop traffic. |
| Authentication or key error | SSH is listening and answered; the failure occurs after the TCP connection. | Check username, authorized keys, identity-file selection, and account policy. |
AWS describes the refusal as occurring when an instance reaches the host but rejects the connection because no service is listening on the SSH port. Google Cloud lists a stopped or misconfigured sshd, a still-booting VM, custom ports, and a kernel panic after an upgrade among common causes. cPanel’s support guidance, updated March 24, 2026, groups the typical causes as SSHD not running, the wrong SSH port, or a firewall blocking the connection.
#1 Best Overall
Google Cloud documentation identifies the problem as: “The OpenSSH Daemon (
sshd) isn’t running or configured properly.”
Get a recovery console before changing anything
SSH cannot repair itself when the daemon is down or the network policy blocks the port. Open the VPS provider’s management panel and use the available browser console, serial console, VNC console, or rescue environment. Google Cloud, AWS, and DigitalOcean document console or rescue paths for situations in which SSH is unavailable; other providers use similar labels.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minute- Record the public IPv4 or IPv6 address shown by the provider and whether the VPS is running, stopped, paused, or still booting.
- Keep the console session open while testing. It is your fallback if a firewall change or service restart cuts the current connection.
- Note the Linux distribution, the expected SSH port, the administrative username, and whether a recent package or kernel upgrade preceded the failure.
- Do not reboot repeatedly before checking logs. Reboots can erase useful context and will not correct a syntax error in
/etc/ssh/sshd_config.
Recover SSH access step by step
1. Verify that the VPS has completed booting
In the provider panel, confirm that the instance is powered on and has finished its boot sequence. A VM that is still starting can reject or ignore SSH while system services are being brought up. If the console shows a kernel panic, emergency mode, a read-only filesystem, or a failed mount, treat that as the primary fault rather than an SSH-only problem.
Once you can log in locally, check failed units and recent boot messages:
sudo systemctl --failed
sudo journalctl -b -p err..alert --no-pagerA kernel regression after an upgrade may require selecting an older kernel from the boot menu or using the provider’s rescue environment. Do not remove the newer kernel until the system is stable and you have a recovery path.
2. Check the SSH daemon and its recent logs
Distributions name the systemd unit either sshd or ssh. Test both names if you are unsure:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
sudo systemctl status sshd
sudo journalctl -u sshd --no-pager -n 50sudo systemctl status ssh
sudo journalctl -u ssh --no-pager -n 50Use the unit that exists on your VPS. The status output tells you whether the daemon is active, failed, or repeatedly restarting. The journal usually states the immediate cause, such as a syntax error, a missing host key, a permission problem, an address already in use, or an inability to read an included configuration file.
If the service is inactive but the logs show no configuration error, start it and then verify its status:
sudo systemctl start sshd
sudo systemctl status sshd --no-pagerSubstitute ssh for sshd when that is the unit name. Do not proceed to a restart until configuration validation in the next step succeeds.
3. Validate every SSH configuration file before restarting
An edit to /etc/ssh/sshd_config or to a file included from it can stop the daemon from starting. Run the built-in syntax test from the console:
sudo sshd -tNo output normally means the syntax check passed. If an error is printed, correct the referenced line and any included file, then run the test again. Common mistakes include a misspelled keyword, an invalid value, a duplicate setting with an incompatible value, a path that does not exist, or a configuration fragment with incorrect permissions.
Only after sshd -t succeeds should you restart the service:
sudo systemctl restart sshdOn systems using the ssh unit, use sudo systemctl restart ssh. If the restart fails, immediately read the corresponding journal entries instead of repeating the command.
4. Find the port sshd is actually configured to use
Port 22 is the default, not a guarantee. An administrator may have moved SSH to another port, or a configuration include may override the value. Ask the running configuration what it will use:
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →sudo sshd -T | grep '^port'The output shows the effective port or ports. Then check which TCP sockets are listening and which process owns them:
sudo ss -tlnp | grep ':22'Replace 22 with the configured port. A listening socket on a different port explains a refusal when the client keeps probing 22. A port conflict can also prevent sshd from starting; the journal will identify the process already using that address and port.
If the daemon is configured for a nonstandard port such as 2222, connect with that port explicitly:
ssh -p 2222 user@SERVER_IPUse the server’s real address, the account that exists on the VPS, and the identity file authorized for that account. Do not assume that changing the client port fixes a server that is not listening anywhere.
Rank #4
5. Check the VPS firewall and the provider firewall separately
There are often two independent policy layers. The guest operating system may run UFW, firewalld, nftables, or iptables, while the hosting platform applies a security group or cloud firewall before traffic reaches the VM. Either layer can block the configured TCP port; changing only one leaves the failure in place.
From the console, inspect the active local firewall. Use the command that matches the firewall you administer:
sudo ufw status verbosesudo firewall-cmd --list-allsudo nft list rulesetsudo iptables -L -n -vLook for a rule that rejects or drops the configured SSH port, and confirm that it allows TCP traffic from the address range you intend to administer. If you changed SSH from 22 to another port, the allow rule must change as well. Permit the port before removing the old rule, and keep the console open until an external test succeeds.
Next, open the provider’s security-group or cloud-firewall page. Verify that an inbound TCP rule allows the effective SSH port and the correct source address. A provider rule can block traffic even when sshd is healthy and listening; a local rule can reject it even when the provider permits it. If you temporarily allow a broad source for recovery, narrow it to your administrative address after access is restored.
6. Investigate host keys, permissions, disk space, and guest-agent failures
When the service log does not make the cause obvious, check the conditions that prevent a normal daemon start:
- Host keys: confirm that the expected files exist under
/etc/ssh/and that the daemon can read them. AWS documents regenerating missing keys withsudo ssh-keygen -A; review the journal afterward and regenerate only when the keys are genuinely absent. - Disk space and inodes: a full filesystem can prevent logs, sockets, or temporary files from being created. Check both capacity and inode use with
df -handdf -i. - File ownership and mode: verify that
/etc/ssh/sshd_config, included fragments, host keys, and their parent directories have restrictive, service-readable permissions. Fix only files that the logs identify; broad recursive permission changes can create a new security problem. - Guest agent: if the provider console reports an unhealthy guest agent, repair that agent or use the provider’s serial or rescue path. The agent problem may be separate from SSH but can explain why panel actions do not reach the guest.
- Boot and kernel state: inspect
systemctl --failed, the current boot journal, and console output for kernel panics, failed mounts, or a filesystem remounted read-only.
These checks distinguish an SSH configuration fault from a broader operating-system failure. If the root filesystem is damaged, continuing to edit SSH files is unlikely to restore reliable service.
Best Value
7. Retest from a client with the exact address, port, user, and key
After the daemon is listening and both firewall layers allow it, retry from your workstation. Specify every value rather than relying on defaults:
Recommended Free Tools
ssh -vvv -p 2222 -i ~/.ssh/id_ed25519 user@SERVER_IPUse -p 22 when 22 is the effective port, and replace the identity path, username, and address with your values. The -vvv output shows address selection, TCP connection progress, key exchange, and authentication. A refusal at the beginning still points to the port, listener, or firewall; a later message indicates that networking is fixed and the remaining issue is authentication or policy.
To test only whether the TCP endpoint answers, use netcat when it is installed:
nc -vz SERVER_IP PORTA successful TCP check does not prove that login will succeed, but it separates transport problems from account, key, or sshd_config access rules. If your client resolves both IPv4 and IPv6 addresses, test the address family that the VPS actually exposes; an unused IPv6 record can make a working IPv4 service appear unavailable.
8. Repair the installation or move to a redeployment plan
If the console shows an unrecoverable boot or filesystem problem, snapshot or copy required data before destructive work. DigitalOcean explicitly advises deciding whether recovery for redeployment is safer than continued troubleshooting. A clean redeployment can be faster and more predictable than repairing a damaged operating system, but it also destroys anything you did not preserve.
Provider-specific checks
| Provider documentation focus | Checks to apply to a refused connection |
|---|---|
| Google Cloud | Use serial-console access when SSH is unavailable. Check whether the VM is still booting, whether SSH uses a custom port, whether a kernel upgrade caused a panic, whether sshd is stopped or misconfigured, and whether the applicable firewall rule permits the port. |
| AWS | Use the instance console or rescue workflow. Review systemctl and journalctl, run sshd -t, inspect listening sockets with ss, verify host keys, and check security-group rules for the effective port. |
| Azure | Confirm that sshd listens on TCP 22 or the configured alternative, inspect local and VM firewalls, verify network-security-group rules, and check intrusion-monitoring software that may reject or alter SSH traffic. |
| Vultr and DigitalOcean | Check provider firewall policies first when the guest service appears healthy, then use the browser or rescue console to inspect the daemon, port, and local firewall from inside the VPS. |
Provider menu names and console availability vary by region, plan, and account settings. The diagnostic principle is the same: prove the guest is running, prove a process is listening, and prove every network policy layer permits that listener.
Repair or redeploy? Use the evidence, not guesswork
Choose repair when the console is usable, the filesystem and boot process appear healthy, and the logs point to a reversible service, port, or firewall mistake. Choose redeployment when the operating system is corrupted, the disk cannot be trusted, recovery time is uncertain, or you have a verified backup and need a predictable restoration time.
Quick Recap
| Decision factor | Repair in place | Redeploy or restore |
|---|---|---|
| Out-of-band access | Best when browser, serial, VNC, or rescue access lets you inspect and correct the guest. | More practical when no console exists and the provider cannot offer a recovery path. |
| Data-preservation requirement | Preserves the current disk and configuration, provided changes are controlled. | Requires a verified snapshot, backup, or data copy; anything not preserved can be lost. |
| Filesystem and boot health | Appropriate when the system boots normally and logs show a focused SSH, port, or firewall fault. | Safer when there is a kernel panic, repeated emergency mode, read-only filesystem, or suspected corruption. |
| Time to restore service | Often quickest for a single bad directive, stopped daemon, wrong port, or firewall rule. | Provides a known clean baseline when troubleshooting has become open-ended. |
| Provider capabilities | Works well when snapshots, rescue instances, and console tools support careful rollback. | Preferable when the provider can rapidly create a replacement and restore your verified data. |
- Take a snapshot or copy essential data before changing partitions, reinstalling packages, or rebuilding the VPS.
- Document the effective SSH port, users, keys, firewall rules, service dependencies, and application configuration.
- Restore to a clean instance only after confirming that the backup contains the data and credentials you need.
- Test SSH through the provider console and from an external client before moving production traffic.
Prevent the next lockout
- Run
sudo sshd -tbefore every restart or reload, especially after editing an included configuration file. - Keep one authenticated SSH session open while testing a new port or firewall rule, and verify a second session before closing the first.
- Record the configured port and keep the corresponding local and provider firewall rules in the same change plan.
- Maintain a tested browser, serial, or rescue-console path. A VPS with browser console access is substantially easier to recover when networking or
sshdfails. - Monitor disk space, failed systemd units, boot errors, and the SSH service so a full disk or repeated crash is visible before the next maintenance window.
- Keep current snapshots or backups and periodically test restoring one; a backup that has never been restored is not a demonstrated recovery plan.
- After changing host keys, ports, or users, update your client configuration and administrative documentation so future tests target the right endpoint.
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.
