Recommended Free Tools
“ssh: connect to host … port 22: Connection timed out” means your SSH client sent a connection attempt but received no TCP response from that address and port. Start with the network path and packet filters: confirm the VPS is running and still has the expected public IP, check the provider firewall or security group, then inspect the VPS firewall and the sshd listener through a console if necessary. A timeout is usually a silently dropped packet; “Connection refused” instead means the destination actively rejected the connection.
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
Work through the checks below in order. Do not change firewall rules over your only remote session without first arranging console or rescue access and allowing the replacement SSH port.
As an Amazon Associate I earn from qualifying purchases.
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 minuteWhat a timeout tells you
A TCP connection needs a response from the selected IP address and port. When that response never arrives, the client eventually times out. Oracle describes the condition this way: “The error means SSH can’t connect to the host at the IP address specified.” A silently dropped packet is the common pattern. An explicit reject more often appears as “Connection refused,” so a timeout should be treated first as a network-path or packet-filtering problem.
The message does not prove that the SSH daemon is stopped. The instance could still be booting, the public IP could have changed, a cloud firewall could be dropping ingress, the guest firewall could be blocking the port, or a broken configuration could have left sshd unable to listen. The diagnostic order below separates those possibilities without assuming one cause.
| Message | What the client learned | First direction to investigate |
|---|---|---|
Connection timed out |
No TCP response arrived from the selected address and port before the timeout. | Instance state, route, provider firewall, guest firewall, then sshd. |
Connection refused |
The destination responded but rejected the connection. | Whether the port is listening and whether a local rule is actively rejecting it. |
Use this order of operations
- Confirm the VPS is powered on, has completed booting, and still owns the public IP you are using.
- Run a verbose SSH attempt and repeat it from a second network or a provider cloud shell.
- Inspect provider security groups, VPC or cloud-firewall ingress, network ACLs, and default SSH rules.
- Through an existing session or console, inspect UFW, iptables, or firewalld.
- Validate
sshd, check its service state, and verify the listening socket. - If ordinary SSH remains unavailable, use serial, browser, rescue, cloud-shell, or attached-disk recovery.
- When all software checks are clean, investigate provider incidents, failed routes, boot-disk problems, kernel failures, disk exhaustion, or an unhealthy VM.
1. Confirm the VPS and its address
Check power and boot state
Open the provider control panel and verify that the VPS is running, not paused, stopped, or being rebuilt. Wait for a reboot, kernel update, or image deployment to finish. Google Cloud lists an instance that has not finished booting as a cause of an SSH timeout. An IP can be correct while the operating system is still unable to accept connections.
Verify the public IP
Compare the address in your SSH command with the current public address shown by the provider. Recreated instances and some network changes can assign a different address. Also confirm that you are using the intended address family: an IPv4 address and an IPv6 address can have different firewall rules and routes.
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 errorsCheck provider health information
Review the provider status page and the instance-health indicators before changing configuration. A regional outage, failed host, or unhealthy virtual machine can make a correctly configured server unreachable. Record the instance ID, region, public IP, and the time the failure began; those details are useful if you need support or recovery.
2. Test from the client side
Run a verbose SSH attempt
Use the actual account, address, and port you intend to use:
ssh -vvv -p PORT user@IPFor the default port, replace PORT with 22. The verbose output shows the address and port selected and whether the client reaches the TCP-connection stage. A timeout before authentication points away from keys and passwords and toward reachability or filtering.
Try a second network
Repeat the same command from a different connection, such as a separate broadband or mobile network, or from the provider’s cloud shell. If one network works while another times out, investigate the failing network’s outbound policy, proxy, VPN, or IPv4/IPv6 path. Oracle recommends checking general internet access and proxy restrictions. If every source fails, the problem is more likely at the provider, VPS, or guest-firewall layer.
Keep the port consistent
If the server was moved from port 22 to a custom port, the client must specify that port with -p. Testing port 22 against a server that listens on another port creates a misleading timeout when a firewall drops unused ports. Google Cloud notes that a custom sshd port requires a matching custom firewall rule.
3. Check provider-side firewalls and network policy
Cloud platforms commonly filter traffic before it reaches the VPS. Inspect every control that can deny ingress:
- Security groups or security lists attached to the instance or network interface.
- VPC or cloud-firewall rules for the instance’s network and region.
- Network ACLs or subnet-level policies.
- The provider’s default SSH rule, if one was created by the image or deployment tool.
Permit TCP traffic to the actual SSH port from the source range you need. For a temporary diagnosis, a narrowly controlled administrator address is safer than opening the port to the whole internet. Once the rule is saved, retry the verbose command. Google Cloud specifically advises checking its firewall rules and default SSH rule; when sshd uses a custom port, the cloud firewall must allow that custom port as well.
Common provider-layer mistakes
- The rule allows TCP 22, but
sshdwas changed to another port. - The rule is attached to a different network interface, tag, security group, or subnet.
- An IPv4 rule exists but the client is reaching the VPS over IPv6, or the reverse.
- The source CIDR excludes the office, VPN, or mobile network currently in use.
- A broad deny rule has higher precedence than the intended allow rule.
Change one provider rule at a time and retest. If the provider console shows dropped packets or flow logs, use those records to confirm whether the connection attempt reaches the cloud boundary.
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 →4. Inspect the VPS firewall
There are usually two independent firewall layers: the provider’s network controls and the guest operating system’s firewall. Passing the first does not guarantee that the VPS will accept the packet.
UFW
From an existing session or an out-of-band console, inspect the active policy:
sudo ufw status verboseUbuntu describes UFW as a user-friendly interface built on iptables. If SSH uses port 22, allow TCP 22; for a custom port, substitute that port:
sudo ufw allow 22/tcpDo not enable or reload UFW until the required SSH rule is present and you have console access. If you are moving SSH to a new port, add the new rule first, confirm that the daemon listens there, and only then remove the old rule.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
iptables
Inspect rules, counters, and policy:
sudo iptables -L -n -vLook for an input policy or rule that drops or rejects the SSH port. A counter that increases when you retry the connection is evidence that traffic reaches the guest firewall. Edit rules using the distribution’s normal persistence method so a reboot does not silently restore a blocking policy.
firewalld
On systems using firewalld, list the active zone and services:
sudo firewall-cmd --list-allEnsure the SSH service or the custom TCP port is allowed in the zone attached to the active interface. A rule in an unused zone will not open the listening interface.
Prevent a lockout
- Keep the current console or SSH session open while testing.
- Allow the new port at the provider firewall and guest firewall before changing
sshd. - Open a second session to verify the change before closing the first.
- Save a known-good rule set or snapshot before major firewall edits.
5. Validate sshd and the listening socket
Check configuration syntax first
Use the provider console, serial console, or rescue environment and run:
sudo sshd -tNo output normally means the configuration passed syntax validation. An error identifies a malformed directive, missing file, or invalid value that can prevent the daemon from starting. Correct the reported issue before restarting the service.
Check the service state
Distributions use either ssh or sshd as the service name:
sudo systemctl status sshsudo systemctl status sshd
Use the name that exists on the system. Google Cloud describes a stopped or improperly configured OpenSSH daemon as a cause of SSH errors. AWS documentation likewise recommends restarting sshd when appropriate and checking that port 22 is listening. Restart only after fixing any configuration error shown by sshd -t.
Verify what is listening
sudo ss -ltnp | grep -E '(:22|ssh)'The result should show a listening TCP socket on the intended address and port. If you use a custom port, replace :22 in the filter or inspect the complete ss output. A daemon bound only to loopback will not accept connections arriving on the public interface. A socket on a different port means the client and both firewall layers must be updated to match.
Restart carefully
After validation, restart the applicable service and check its status again. Keep the console open until a new SSH session succeeds. If the service fails immediately, return to the syntax check and the service logs available in the provider console or rescue environment rather than repeatedly restarting it.
The SSH port must match at every layer
A custom port works only when four settings agree: the client command, the provider firewall, the guest firewall, and the sshd listener.
| Layer | What to verify | Example check or setting |
|---|---|---|
| SSH client | The port in the command or SSH configuration. | ssh -p 2222 user@IP |
| Provider network | Ingress permits TCP to that port from the required source range. | Cloud firewall or security-group rule for TCP 2222. |
| Guest firewall | UFW, iptables, or firewalld permits the same port. | Allow TCP 2222 in the active guest policy. |
| sshd | The daemon listens on that port and is running. | sudo ss -ltnp shows the SSH socket. |
Changing only one layer creates a timeout that can look like a routing failure. Document the selected port and update all four locations together.
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 →6. Recover through an out-of-band console
When network SSH is unavailable, use a path that does not depend on the blocked TCP port. Depending on the provider and VPS type, options include:
- Serial console: a terminal connection to the VM for checking boot messages, firewall rules, and services.
- Browser console: an in-panel terminal that needs no network route from your workstation.
- Rescue mode: a recovery image from which you can mount the system disk and repair configuration.
- Cloud shell: a provider-hosted shell useful for testing reachability and using provider APIs or console features.
- Attached-disk recovery: attach the boot disk to a working recovery instance, edit the broken configuration, and reattach it.
Google Cloud recommends investigating sshd problems through its serial console. Oracle documents alternate access and Cloud Shell options. A physical USB-to-serial adapter is relevant only to a host with a compatible physical serial interface; it is not required for a browser-based cloud console.
What to do in the console
- Confirm the system finished booting and that the root filesystem is mounted read-write.
- Run
sudo sshd -tand correct the reported configuration error. - Inspect
sudo systemctl status sshorsudo systemctl status sshd. - Check
sudo ss -ltnpfor the intended listening port. - Inspect and correct UFW, iptables, or firewalld rules.
- Test a new SSH session from a second terminal before ending the console session.
7. When the software checks are clean
Look for infrastructure incidents
If the VPS is healthy, the provider rule allows the port, the guest firewall allows it, and sshd is listening, check for a provider incident or failed route. Compare results from multiple networks and the provider cloud shell to distinguish an external path problem from a VM problem.
Investigate boot and kernel failures
A kernel panic or failed upgrade can leave the address allocated while the operating system never reaches a usable state. Use serial output or rescue mode to inspect boot messages. Google Cloud documents recovery by reverting or repairing the boot disk when a kernel failure prevents normal startup.
Check disk and instance health
A full filesystem can prevent services from starting or writing logs. An unhealthy or stopped VM can similarly retain an address without accepting connections. Use the provider’s health checks and console, then free space or repair the instance only after preserving important data.
Choose recovery or redeployment deliberately
If the instance cannot be restored, decide whether the priority is data recovery or a clean replacement. DigitalOcean’s guidance frames this as a recovery-versus-redeployment decision. Snapshot or copy required data before rebuilding, and record the firewall and SSH settings that must be recreated on the replacement.
Symptom-based branches
| Observation | Likely boundary | Next action |
|---|---|---|
| Timeout from every network, and the instance is still booting | Boot or infrastructure state | Wait for completion, inspect health indicators, then use serial or browser console. |
| Timeout from every network, but the instance is healthy | Provider firewall, guest firewall, or sshd |
Check cloud ingress, guest rules, daemon syntax, service state, and socket. |
| Works from one network but not another | Client network, proxy, VPN, or address-family path | Compare IPv4/IPv6 use and outbound restrictions on the failing network. |
| Port 22 times out after moving SSH | Port mismatch | Use ssh -p PORT and open that port at both firewall layers. |
| Connection refused instead of timed out | Destination is reachable but no rule or listener accepts the connection | Check the listening socket, service state, and active reject rules. |
Prevent the next lockout
- Keep provider console or serial access enabled before making firewall or SSH changes.
- Record the public IP, selected SSH port, provider rule, guest-firewall rule, and service name.
- Use a second session to test every change while the original session remains open.
- Maintain current snapshots or backups so a failed boot-disk repair does not become data loss.
- After upgrades, verify that the VM completed booting and that
sshdis listening. - When selecting a VPS, compare the clarity of provider firewall controls, availability of browser or serial rescue access, boot-disk recovery options, support for custom SSH ports and IPv6, and snapshot or redeployment controls.
A compact recovery checklist
- Is the VPS powered on and finished booting?
- Does it still have the public IP used by the SSH command?
- Does
ssh -vvv -p PORT user@IPshow the intended port? - Does a second network or provider cloud shell produce the same result?
- Does the provider firewall allow TCP to that port from your source?
- Does UFW, iptables, or firewalld allow it inside the VPS?
- Does
sudo sshd -tpass? - Is the correct
sshorsshdservice running? - Does
sudo ss -ltnpshow the expected listener? - If not, can serial, browser, rescue, cloud-shell, or attached-disk recovery repair it?
Following those checks isolates the failure boundary instead of treating every timeout as a key or password problem. The practical rule is simple: verify the instance and address, trace the packet through provider and guest firewalls, then prove that sshd is listening on the same port the client uses.
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.
Free tools Windows power users keep installed
One-click scans. No signup required.
