When SSH works from your office but fails from home, the server may still be healthy. Diagnosing network-specific SSH failures means comparing two connection paths, not rebuilding the SSH service. A different network can change your public address, destination address, VPN route, or security policy.
SSH, or Secure Shell, provides encrypted remote access to a server. This guide focuses on location-dependent failures. The goal is to identify exactly where the working and failing paths differ before changing access controls.
Protect Working SSH Access During Network Tests
Keep an existing administrative session open while investigating. Confirm that you can reach a hosting console or another approved recovery method. A working session does not guarantee that a new connection will succeed.
Avoid disabling the firewall, clearing every ban, or exposing SSH to all internet addresses. Those changes remove useful evidence and can create unnecessary risk.
Use the same laptop, SSH client, username, destination, and port on both networks where possible. Switch only the network connection. Run one controlled attempt from each location and record the time, including its time zone.
- Record whether the VPN is connected.
- Save the exact error and destination address.
- Note the public source address visible at the server or edge firewall.
- Record any recent firewall, ISP, router, or VPN changes.
This paired comparison distinguishes network-specific SSH failures from client changes that merely coincide with a location change.
Compare SSH Destinations and Connection Stages Across Networks
Matching hostnames do not always mean matching servers. Internal DNS may return a private address, while external DNS returns a public address. Client configuration can also select a different port or jump host.
On systems with the OpenSSH client, inspect the effective settings and capture a verbose attempt:
ssh -G server-alias
ssh -vvv -o ConnectTimeout=10 server-aliasReplace server-alias with your configured destination. Review the hostname, port, proxy settings, and address family. Verbose output shows the address and port that the client actually tries.
Treat debug logs as sensitive. They can reveal usernames, internal addresses, file paths, and infrastructure details. Remove sensitive details before sharing them.
- Timeout before connection: investigate filtering, routing, and the return path.
- Immediate refusal: check the destination listener and active rejection rules.
- Authentication failure: the connection reached an SSH service; compare identities and source-dependent login policy.
For error interpretation, see our guide to refused versus timed-out SSH connections. Here, use those errors to compare locations rather than diagnose a general server outage.
Check Source-Based Firewall Rules and IP Access Lists
An access control list, or ACL, permits or denies traffic using defined conditions. SSH rules often allow only an office public address or an approved VPN range.
Check every enforcement layer: hosting firewall, perimeter firewall, server firewall, and any managed access gateway. An allow rule on the Linux host cannot override a block at the hosting edge.
Compare the source address in connection logs with the allowed range. Do not assume that your laptop’s private address reaches the server. Network address translation, or NAT, often replaces it with a router’s public address.
Home connections may change public addresses. Business failover links can also use different outbound addresses. Either change can invalidate an otherwise correct allowlist.
Geo/IP controls add another layer. These rules may classify addresses by country, network owner, or reputation. Their classifications can be wrong or outdated. Check the actual matched rule and its address data before requesting a narrow exception.
Also inspect SSH configuration for source-dependent Match Address conditions. These can change authentication requirements without blocking the network connection itself.
Inspect fail2ban Without Removing Every Ban
fail2ban watches logs and can temporarily block addresses after repeated failures. Several users behind one public address may share the same ban.
On servers that use fail2ban, inspect its status through an existing session or console:
sudo fail2ban-client status
sudo fail2ban-client status sshdThe second command assumes a jail named sshd. A jail combines log matching with a response, such as a firewall ban. Names and available commands depend on the installation.
Compare the failing source address with the active bans. Review the triggering events and timestamps. Old credentials, automated jobs, or another user behind shared NAT may explain repeated failures.
After confirming the cause, an authorized administrator can remove the specific ban. Correct the bad credentials or automation first, or the next attempt may trigger another block.
Do not add broad trusted ranges merely to avoid future bans. Repeated network-specific SSH failures deserve a source-level explanation, not a permanent bypass.
Separate IPv4 and IPv6 Paths
A hostname can resolve to both IPv4 and IPv6 addresses. Different networks may give the client different usable address families. As a result, one location can reach a healthy IPv4 listener while another attempts broken IPv6 connectivity.
With OpenSSH, compare explicit address-family tests:
ssh -4 -vvv -o ConnectTimeout=10 server-alias
ssh -6 -vvv -o ConnectTimeout=10 server-aliasRecord each destination address and result. Failure without a usable IPv6 route does not prove a server fault.
On the server, an administrator can inspect listening sockets:
sudo ss -lntpCheck the configured SSH port and its bound addresses. Do not assume that an IPv6 wildcard listener also accepts IPv4 on every system. The ss manual explains the socket inspection options.
Compare firewall policy for each address family, too. IPv4 and IPv6 may follow different routes and security rules. Forcing IPv4 can help isolate the fault, but it does not repair the IPv6 path.
Trace VPN Routes, NAT, and Return Traffic
A VPN changes more than encryption. It can change DNS answers, route selection, and the source address that the destination sees.
For each approved test, record whether SSH travels through the tunnel or directly over the internet. A split tunnel sends only selected destinations through the VPN. A full tunnel generally carries ordinary internet traffic too.
On Linux, inspect the route to the actual destination:
ip route get DESTINATION_IPV4
ip -6 route get DESTINATION_IPV6Replace the placeholders with the addresses from the SSH debug output. Check the selected interface, gateway, and source address. Run these commands in the same host or network context as the SSH client.
Private subnet overlap can send traffic toward a local device instead of the VPN. Our guide to diagnosing VPN home subnet conflicts covers that specific condition.
For a public SSH endpoint, also check inbound port forwarding and loopback NAT behavior. An internal test through a public address may follow a different path. Review when double NAT matters if multiple routers handle the connection.
Finally, verify the server’s route back to the observed client source. An incoming connection can fail when replies leave through the wrong gateway.
Test ISP Filtering With Evidence, Not Assumptions
A successful hotspot connection shows that another path works. It does not identify which provider, firewall, or policy caused the original failure.
Use authorized firewall logs or a narrowly filtered packet capture during one timed attempt. For TCP, the transport protocol SSH normally uses, compare these observations:
- No connection request reaches the edge: investigate the client network and upstream path.
- Traffic reaches the edge but not the host: inspect edge filtering and forwarding.
- Host replies never reach the client: investigate return routing and downstream filtering.
- Login fails after the connection completes: inspect SSH policy and authentication evidence.
Capture only the traffic needed for diagnosis, and handle captures as sensitive data. Missing host traffic alone cannot prove ISP filtering.
If policy permits, a successful VPN test can narrow the investigation. However, it changes both routing and source identity. Ask the network owner or ISP to verify restrictions using timestamps, destination details, and observed packet evidence.
Apply a Narrow Fix and Retest Both Networks
Resolve network-specific SSH failures at the layer that caused them. Update a stale approved source address, correct a confirmed ban, repair the VPN route, or align IPv6 listener and firewall settings.
Change one item at a time and document a rollback. Then open fresh sessions from both networks. Verify that intended access works and unrelated sources remain restricted.
When you lack console access or cannot identify the blocking layer, professional remote assistance may be appropriate. Tech Rescue Ops LLC can help compare the paths, review access controls, and plan a targeted correction without broadly exposing SSH.