When the Connection Itself Is the Problem

Remote Support Tools & Techniques

Chapter 8 · When the Connection Itself Is the Problem

Network Troubleshooting already taught the general diagnostic toolkit — DNS, ping, port checks, firewalls. This chapter isn't new technical territory so much as that same toolkit aimed at one specific, narrower question: "I'm trying to reach an SSH, RDP, or VNC service on a specific host, and it isn't working."

The First Question: Is It Me, or Is It Them?

The same scoping instinct netdiag1 opens with, applied here directly: can you reach other things fine? If yes, the problem is specific to this one host or service, not your general connectivity. Testing from a genuinely different network — your phone's own mobile data, for instance — isolates whether the problem is your specific location or something about the target itself.

Common SSH Connection Failures, Precisely Read

Reusing netdiag1's own "refused vs. timed out" distinction (Chapter 6), applied specifically to SSH:

$ ssh jumphost.company.com ssh: connect to host jumphost.company.com port 22: Connection refused $ ssh jumphost.company.com ssh: connect to host jumphost.company.com port 22: Operation timed out $ ssh jumphost.company.com jlee@jumphost.company.com: Permission denied (publickey).
ErrorWhat it actually means
Connection refusedNothing is listening on port 22, or a firewall explicitly rejected it — netdiag1's own network-level distinction
Operation timed outA firewall silently dropping the connection, or a genuine network-path problem — also netdiag1's territory
Permission denied (publickey)The network connection and SSH handshake both actually succeeded — this is an authentication failure, not a connectivity one
A genuinely different category, easy to conflate
"Permission denied" means you reached the server just fine — the problem is specifically that your key isn't in authorized_keys, the wrong key is being offered, or the wrong username was used. This is Chapter 2's territory, not netdiag1's — treating it as a network problem sends the investigation in a completely wrong direction, even though it also happened "at connection time."

A Practical Checklist, In Order

  1. Can I reach anything else at all? (scope)
  2. Can I reach the host at the network level — ping, or a route that completes? (netdiag1 Chapter 5)
  3. Is the specific port actually open? (netdiag1 Chapter 6 — nc -zv host 22 for SSH, nc -zv host 3389 for RDP)
  4. If the port is open but the connection still fails — is this actually an authentication problem, not a network one? (Chapter 2's own authorized_keys material)

RDP-Specific Connection Failures

RDP has its own distinct failure modes worth recognizing on sight, rather than mistaking for a network problem: "The remote computer requires Network Level Authentication, which your computer does not support" is a real, specific, named error indicating a client/server security-mode mismatch — not a connectivity issue at all. Similarly, a connection refused specifically due to a server already at its concurrent RDP session limit is a licensing/capacity condition, again nothing to do with the network path.

Don't blame the firewall first
Jumping straight to "the firewall must be blocking me" is a common overreaction. The actual cause is very often something far more mundane — a typo in the hostname, the service genuinely being down, the wrong port, an expired VPN session. The same "check first, don't reach for the most dramatic-sounding explanation" discipline this entire subject has built on applies here too.

Working Example: "SSH to the Jump Host Stopped Working This Morning"

Working the checklist: other services reach fine — not a general network problem. A ping to the jump host times out. A traceroute shows the path dying at the exact same hop that always used to pass through cleanly — genuine network-path evidence, not an SSH-specific issue at all. This gets escalated as a plain netdiag1-style network finding to the network team, rather than treated as an SSH problem — "I can't SSH in" often turns out to be an ordinary network-layer problem wearing an SSH-shaped disguise, and the diagnostic techniques from that course apply completely unchanged.

Hands-On Exercises

Exercise 1

Explain why "Permission denied (publickey)" is described as a genuinely different category of failure from "Connection refused" or a timeout, even though all three happen at connection time.

📄 View solution
Exercise 2

Explain why the RDP "Network Level Authentication" error shouldn't be diagnosed the same way as a network connectivity failure.

📄 View solution
Exercise 3

In this chapter's working example, explain why the "SSH stopped working" ticket was escalated as a network finding rather than an SSH-specific one, and what evidence supported that conclusion.

📄 View solution

Chapter 8 Quick Reference

  • This chapter applies netdiag1's own toolkit to one narrow question: why can't I connect in
  • Scope first: can you reach other things fine? Test from a different network to isolate location vs. target
  • Refused/timeout = network-level (netdiag1 territory); "Permission denied (publickey)" = authentication succeeded reaching the server, then failed — Chapter 2's territory
  • Ordered checklist: reach anything → reach the host → the specific port is open → is this actually auth, not network
  • RDP has its own distinct errors (NLA mismatch, session-limit refusal) — neither is a network problem
  • Don't jump to "the firewall" first — the mundane explanation is usually right
  • Next chapter: Session Logging & Audit Trails for Remote Access