Your Linux server was accepting SSH connections yesterday. Now the terminal reports “Connection refused,” “Connection timed out,” or “Permission denied.” The server may still be running normally, but you cannot get in.
When SSH is not working, restarting the server is rarely the best first diagnostic step. A wrong IP address, blocked port, stopped service, rejected key, or unexpected configuration change can produce different failures. The useful first step is to identify where the connection stops.
This 12-check troubleshooting workflow starts on your own computer. If SSH is unavailable, it continues through your VPS provider’s web or serial console. The goal is to identify the cause, make only a justified change, and confirm that remote access is restored.
If SSH is not working, begin with the exact error message. A timeout points toward a connection that did not complete; a refused connection suggests an active rejection or missing listener; a permission-denied result usually means the connection reached authentication but login failed.
Verify the target IP address, SSH port, client configuration, network path, server listener, firewall rules, and authentication settings in that order. Do not reboot merely because the first connection attempt failed.
Before you change anything
If one SSH session still works, keep it open. If all SSH access is lost, use your provider’s authorized recovery console for server-side checks. Do not blindly restart SSH, change firewall rules, disable security controls, or reboot a production server without a recovery plan.
- SSH Not Working? Identify These Three Errors First
- Connection timed out
- Connection refused
- Permission denied
- Understand Where SSH Can Fail
- The 12-Point SSH Troubleshooting Checklist
- Read the exact SSH error
- Verify the server IP address and DNS
- Confirm the username, port, and SSH client settings
- Test TCP reachability without changing the server
- Use verbose SSH output to locate the failing stage
- Confirm that the server and its network are actually available
- Inspect the SSH service and socket activation state
- Verify the port and address accepting SSH connections
- Inspect both Linux firewall rules and cloud firewall policy
- Verify the account, key, and permitted login methods
- Read SSH logs and validate the configuration
- Apply only the justified fix and test a fresh SSH connection
- Which Check Should You Prioritize?
- Five Mistakes That Can Make an SSH Outage Worse
- When Rebooting Might Actually Be Necessary
- Knowledge Check
- Official Technical References
SSH Not Working? Identify These Three Errors First
These messages describe different points of failure. Treat them as diagnostic clues, not definitive proof of one cause.
Connection timed out
The connection did not complete within the allowed time. Possible causes include an incorrect destination, packet filtering, routing problems, or an unreachable server.
Trace the network path →Connection refused
The TCP connection was actively rejected. Nothing may be listening on that address and port, or a firewall or intermediary may be rejecting the attempt.
Inspect the SSH listener →Permission denied
The SSH client usually reached the authentication stage, but the server did not accept the offered credentials or login method.
Inspect authentication →A message such as REMOTE HOST IDENTIFICATION HAS CHANGED is different. It is a host identity warning, not a routine password failure. Stop and independently verify the server’s current host-key fingerprint through a trusted source before changing any known-hosts entry.
Understand Where SSH Can Fail
An SSH login passes through several independent components before you see a shell.
A simplified diagnostic path. The actual network may include DNS, NAT, load balancers, VPNs, and additional filtering layers.
If your client cannot reach the server’s TCP port, investigating SSH keys is premature. If the connection reaches authentication, restarting the network is unlikely to explain an incorrect username.
This distinction builds on Linux networking, IP addresses, routes, and gateways and how listening ports and sockets work.
The 12-Point SSH Troubleshooting Checklist
Use the following checks in order, skipping a check only when you already have reliable evidence that it is not relevant. Tick each checkbox after inspecting the result. The marks are local to this page and reset when it is reloaded.
All sample connections use the documentation IP address 203.0.113.10, the example hostname server.example, and the sample account deploy. Replace them with your real values. The examples assume an OpenSSH client and a Linux server; server-side service commands assume systemd.
Start with a single connection attempt, using the address and username you expect to use.
ssh -o ConnectTimeout=8 deploy@203.0.113.10The connection timeout option limits how long the client waits during connection establishment and the initial handshake. It does not identify the cause by itself.
What to look for: Record whether the failure concerns name resolution, connection refusal, timeout, host identity, authentication, or an immediate disconnect. Those are different branches of the investigation.
Confirm the public IP or hostname from your hosting provider’s dashboard. Do not assume that an address saved months ago is still assigned to your server.
If you normally connect by hostname, inspect its resolution. On a Linux client with getent:
getent ahosts server.exampleCompare the returned addresses with the provider’s current details. Also consider whether the hostname has IPv4 and IPv6 records: one address family could be failing while the other works.
Temporarily testing the confirmed IP directly can help separate a hostname-resolution problem from a later connection problem.
What it means: If the hostname resolves to an outdated or unintended address, fix that discrepancy before modifying SSH on the server.
SSH commonly uses TCP port 22, but a particular server may be configured for a different port. A local SSH configuration file can also override the hostname, username, port, identity file, or jump host.
ssh -G server.exampleLook for entries such as hostname, user, port, identityfile, and proxyjump. Do not publish the full output without reviewing potentially sensitive local paths and connection settings.
To test a confirmed custom port, for example 2222:
ssh -p 2222 deploy@203.0.113.10What it means: A correct server at the wrong TCP port can look unreachable. Confirm the actual port instead of guessing alternative ports.
On a client with Netcat installed, test the specific SSH TCP endpoint:
nc -vz -w 5 203.0.113.10 22A successful TCP connection shows that this endpoint accepted the TCP connection. It does not prove that authentication works or even that the application behind the port is SSH.
If the connection times out, compare the result from another trusted network when available. VPN policies, office firewalls, public Wi-Fi networks, and source-IP allowlists can affect the path.
On a Linux client, you can also inspect its chosen route:
ip route get 203.0.113.10What it means: If one network works and another does not, investigate network-specific filtering, routing, VPN policy, or source-address restrictions before restarting your VPS.
OpenSSH can explain which configuration and connection stages it reached.
ssh -vvv -o ConnectTimeout=8 deploy@203.0.113.10Read the output chronologically. It may show which destination is selected, whether a TCP connection is established, whether key exchange begins, and which authentication methods are attempted.
If the diagnostic trace reaches public-key authentication, you can focus on account and key settings. If it stops during TCP connection establishment, server-side authentication settings are not yet the useful starting point.
What it means: Debug output narrows down the failure stage. It is evidence, not automatically a complete diagnosis. Review and redact hostnames, usernames, paths, and addresses before sharing logs.
Access requirement: Checks 6–11 require a working server shell. If SSH is completely unavailable, obtain access through your hosting provider’s authorized web console, serial console, or documented recovery method. These are not commands you can execute on the inaccessible server from your local terminal.
Use your provider dashboard to confirm that the intended VPS or instance is running and that no documented maintenance, suspension, or network incident explains the outage.
Once you have console access, inspect the server’s interfaces and routes:
ip -br address
ip routeCompare the configured addresses and routing information with the expected environment. Some cloud platforms use private addresses inside the guest and provide public connectivity through external NAT, so the public IP may not appear directly on a guest interface.
What it means: A server can be powered on but lack the expected network configuration. Resolve that discrepancy before investigating SSH authentication.
OpenSSH server units are not named identically on every Linux distribution. Debian and Ubuntu commonly use ssh.service, while other systems use sshd.service.
systemctl status ssh.service --no-pagerIf that unit is absent, inspect:
systemctl status sshd.service --no-pagerSome installations use systemd socket activation. Where applicable, also inspect ssh.socket or sshd.socket. A service’s inactive state does not always mean the SSH endpoint is unavailable when a socket unit manages incoming connections.
Look for failed startup messages, missing configuration, or repeated failures. Do not restart the service until you know why it is stopped and how to recover from an unsuccessful change.
What it means: Service status helps distinguish a stopped or failed server component from an active service whose network path is blocked. Learn the difference between service state and startup configuration in our systemctl guide.
An active service indicator does not prove that the expected TCP port is listening on the expected interface.
ss -ltnLook for the configured SSH port under the local address column. A listener bound only to 127.0.0.1:22 is not directly reachable from another machine through the server’s public interface.
A listener on 0.0.0.0:22 covers the system’s IPv4 addresses, subject to other restrictions. IPv6 listening behavior must be considered separately because it can depend on the socket and system configuration.
With appropriate permission, sudo ss -ltnp may also identify the owning process. Under socket activation, that process may be systemd rather than a persistent sshd listener.
What it means: If the expected port is not listening, focus on SSH configuration or activation. If it is listening locally but cannot be reached remotely, inspect the network and filtering path.
A working SSH listener can still be unreachable when inbound traffic is blocked or rejected. This can happen in the guest operating system, at the hosting provider, or along an intermediate network path.
Choose the read-only inspection command for the firewall system your server actually uses.
sudo ufw status verbosesudo nft list rulesetsudo firewall-cmd --list-allDo not assume these tools are all installed or that a single command displays every active policy. firewalld may have multiple zones; other rulesets and external firewalls can also affect traffic.
Compare the actual SSH port, protocol, source-address restrictions, interface, and IPv4/IPv6 policy. Then inspect the cloud provider’s inbound firewall or security-group rules separately.
What it means: A permitted firewall port does not start SSH, and a listening SSH service does not automatically bypass a firewall. See how Linux firewall rules control network traffic.
If SSH reaches authentication and reports Permission denied (publickey), the server did not accept the offered public-key authentication for that login attempt.
Start by confirming that the target account exists:
getent passwd deployReview the account’s home directory and the expected authorized_keys location. If this user’s home is /home/deploy, the following is a read-only inspection:
sudo ls -ld /home/deploy \
/home/deploy/.ssh \
/home/deploy/.ssh/authorized_keysCheck ownership, write permissions, whether the correct public key is present, and whether the account or policy restricts login. The actual authorized-key path can differ from the default. OpenSSH settings such as PubkeyAuthentication, AuthorizedKeysFile, AllowUsers, and Match can affect the result.
On your own computer, confirm which private key the SSH client is selecting. A private key must remain private; never upload it to a troubleshooting page or paste it into a public discussion.
What it means: The server may be reachable and healthy even though your identity is rejected. Do not enable password authentication or weaken security restrictions merely to silence the error.
Logs can reveal authentication failures, configuration problems, blocked accounts, and failed daemon starts. On a systemd-based Ubuntu or Debian server:
sudo journalctl -u ssh.service \
-b -n 80 --no-pagerOn systems using sshd.service, substitute that unit name. Depending on the logging setup, SSH events may also be recorded in other journal entries or distribution-specific log files.
For a standard OpenSSH server installation, validate its configuration and host-key sanity without restarting it:
sudo /usr/sbin/sshd -tNo output with a successful exit status generally indicates that this test found no configuration or key sanity problem. The executable path can differ across systems.
To inspect effective configuration settings, OpenSSH also supports sshd -T. More advanced configurations using Match directives may require -T -C with the relevant connection parameters to evaluate a specific client context.
A clean syntax check does not prove that firewall rules, authentication, DNS, or routing are correct.
What it means: Compare the first observed failure with the server-side evidence. Fix the demonstrated cause rather than applying several speculative changes at once.
Before changing anything, record the current state. Back up any configuration you intend to edit, understand the expected impact, and keep provider-console or other out-of-band access available.
If the issue concerns sshd configuration, validate the edited configuration before a controlled reload or restart. Follow the service management procedure appropriate to your distribution and activation model.
If the issue concerns firewall rules, ensure your intended management address and SSH port are permitted before enforcing a restrictive change. Plan how to revert a failed rule update.
After the targeted fix, test again from your own computer:
ssh -o ConnectTimeout=8 deploy@203.0.113.10Use the real configured port if it differs from 22. Verify that you reach the intended server, authentication succeeds, and a fresh session can be established.
Do not close an existing working session or recovery console until the new connection has been verified. Record the actual cause and the correction for future incidents.
What it means: A successful new connection is better evidence of recovery than a green service-status indicator alone.
Which Check Should You Prioritize?
When time is limited, use the failure stage to prioritize the investigation without treating a message as a guaranteed diagnosis.
| Observed failure | Useful first checks | What to investigate |
|---|---|---|
| Hostname cannot be resolved | 2, 3 | DNS, hostname, client configuration |
| Connection timed out | 2, 4, 6, 9 | Destination, route, filtering, instance reachability |
| Connection refused | 3, 7, 8, 9 | Port, listener, service, explicit rejection |
| Permission denied | 3, 5, 10, 11 | Username, keys, account policy, authentication logs |
| Host identity changed | 2, 3, identity verification | Wrong destination, legitimate key rotation, or possible interception |
Five Mistakes That Can Make an SSH Outage Worse
- Rebooting before identifying the failure. A reboot does not fix an incorrect destination, an external firewall rule, or a rejected key. It may also interrupt healthy workloads.
- Restarting SSH before validating its configuration. An invalid server configuration can prevent the service from starting again.
- Disabling the firewall to test connectivity. This can expose unrelated services. Inspect the specific rule and understand the risk before making a targeted change.
- Disabling host-key verification. A changed host key requires identity verification. Suppressing the warning removes an important SSH security check.
- Closing the only working session too early. A successful status command is not a substitute for opening a second, independent SSH connection.
Practical rule: Troubleshooting is an evidence-driven sequence: observe the error, identify the failing layer, inspect the relevant state, apply one justified correction, and verify recovery.
When Rebooting Might Actually Be Necessary
A reboot may be justified when the identified problem requires restarting the operating system, when the server is genuinely unresponsive and recovery procedures have been exhausted, or when the hosting provider’s supported recovery process calls for it.
That is different from rebooting because SSH returned an error. A running system with a blocked port or a wrong username does not normally need an operating-system restart to explain the failure.
Before a planned reboot, confirm backups where relevant, understand the effect on workloads, retain a recovery route, and know how to validate services afterward. The Linux Server Health Check Checklist provides a broader set of read-only system inspections.
Knowledge Check
1. SSH reports “Connection refused.” Should you immediately replace your SSH key?
No. A refused TCP connection suggests you should first inspect the destination port, SSH listener, service state, and possible active rejection. Authentication may not have started.
2. The SSH service is active, but remote connections time out. Is SSH definitely healthy?
No. Service state alone does not verify the listening address, external connectivity, firewall policy, or routing. Inspect the socket and network path.
3. A client reports “Permission denied (publickey).” What does this suggest?
The connection generally reached authentication, but the offered key-based login was not accepted. Check the account, selected private key, authorized public key, access restrictions, and server logs.
4. What is the difference between sshd -t and sshd -T?
The -t option validates the server configuration and key sanity. The -T option checks configuration and prints effective settings. Context-specific Match rules may require additional -C parameters.
5. Why should you open a second SSH connection after a configuration change?
A second connection tests whether new logins still work. An existing session may survive a change even while new connections fail.
An SSH error is a clue about the connection path, not an instruction to reboot. DNS, routing, firewall filtering, listening sockets, service configuration, and authentication are separate layers. Test them in an order that follows how an SSH connection is established.
Start with the exact client error, work toward the server only as the evidence requires, and use the provider console when remote access is gone. The safest fix is the smallest change that addresses a demonstrated cause.
A recovered server is not merely one that reports an active SSH service. It is one where you have verified that a new, authenticated remote session works and that you retain a reliable recovery path.
Official Technical References
- OpenSSH Manual — ssh(1): client options and connection diagnostics.
- OpenSSH Manual — ssh_config(5): client configuration and option precedence.
- OpenSSH Manual — sshd(8): server operation and configuration test modes.
- OpenSSH Manual — sshd_config(5): authentication and server configuration.
- Ubuntu Server Documentation — OpenSSH Server: supported Ubuntu SSH administration and safety guidance.
- Linux man-pages — ss(8): socket and listening-port inspection.
