## Scenario A previously reachable Linux host can no longer be accessed over SSH. Build a layered troubleshooting plan using tools such as `ping`, `traceroute`, `ss`, `lsof`, service logs, and SSH client diagnostics. Explain what each observation proves and what it does not prove. ### Constraints & Assumptions - Begin from a client with network access and, if needed, use an approved console or out-of-band path to inspect the server. - Avoid disabling authentication or firewall controls merely to make the connection work. - Minimize changes until the failing layer is identified. ### Clarifying Questions to Ask - Is the failure a DNS error, timeout, connection refusal, host-key error, or authentication rejection? - Does it affect one user, one source network, or every client? - Were routing, firewall, SSH configuration, keys, or host capacity changed recently? - Is an out-of-band console available? ```hint Follow the connection path Resolve the name, establish IP reachability and route, test the TCP port, confirm a listener, then investigate protocol and identity checks. ``` ### What a Strong Answer Covers - DNS, routing, filtering, TCP reachability, listening sockets, daemon health, and authentication as separate layers. - Correct interpretation of ICMP results and why failed ping does not prove the host is down. - `ssh -vvv`, `nc` or equivalent TCP tests, `ss -lntp`, `lsof -i`, logs, disk/inode pressure, and key permissions. - Safe rollback or remediation with an alternate session kept open when editing SSH configuration. ### Follow-up Questions 1. How would you distinguish a security-group drop from a local daemon refusal? 2. Why can a full filesystem break login even when the SSH listener is healthy? 3. What extra checks apply when a bastion or proxy jump host is involved?