What a failed SSH connection actually tells you
Compute Engine runs virtual machines; SSH provides an encrypted terminal into a Linux guest. A failed connection does not automatically mean the VM is down. An administrator can lose access while customer requests continue to work. Start by recording whether the client reports a timeout, a refused connection or a rejected identity. These observations lead to different investigations.
Google's troubleshooting tooling checks several layers, including permissions and connectivity. OS Login, metadata-based SSH keys and an Identity-Aware Proxy tunnel introduce different access dependencies. Establish which path this VM is intended to use before comparing policies. A working browser session under one account is not proof that a different command-line principal has the same access.
Establish a supportable starting configuration
- Record the project, zone, VM name, guest image, network and approved administrative route. Confirm that the operating team can find the VM without relying on a private IP copied into a chat.
- Document the identity mechanism and the team responsible for account lifecycle. Separate permission to reach a tunnel from permission to log into the guest.
- Configure scoped network access, guest logging and a reviewed recovery method. Test a normal login and an expected denied login from separate identities before handover.
Use a non-production VM for policy rehearsals. Console options and required roles vary with the chosen login configuration; use the linked provider instructions for those details.
Illustrative incident: one operator is locked out
A platform engineer changes teams and their account loses the login permission required by the existing VM policy. Another engineer can still connect through the approved tunnel. The application remains healthy. This is an illustrative scenario, not a reported Clouvenix client engagement. Opening TCP 22 to the internet would expand exposure without repairing the engineer's identity permission.
Gather evidence without changing the access model
The following diagnostic pattern uses placeholders. Replace them with approved resource identifiers; do not paste private keys into diagnostic output.
gcloud compute ssh VM_NAME --zone=ZONE --project=PROJECT_ID --troubleshoot
For an environment that intentionally uses IAP, include the documented tunnel option rather than treating a direct public connection as an equivalent test. The troubleshooting tool can request permission for its diagnostic tests, so review that prompt and retain only the relevant result.
| Observation | Evidence to collect | Decision it supports |
|---|---|---|
| Only one identity fails | Principal and login-policy comparison | Account or policy investigation |
| Every approved source times out | VM status and intended network path | Reachability investigation |
| Connection reaches the guest but is rejected | Guest authentication events and username | Guest identity investigation |
Compare timestamps in one timezone. If no guest event appears, determine whether the connection reached the guest before resetting its SSH service.
Repair the demonstrated fault and prove recovery
Have the identity owner review the intended access entitlement. Apply a narrowly scoped correction through the established change process and preserve the prior policy for reversal. If evidence instead identifies a guest problem, use the approved recovery route and record that separate finding. Avoid changing identity, firewall and guest configuration together; the resulting success would not explain which change was necessary.
Verify a fresh login from the affected identity through the original intended route. Confirm the previously denied identity is still denied, and check that application traffic was unaffected. A successful login from an administrator's unrelated account is insufficient acceptance evidence.
Monitoring, reliability and handover
Measure successful approved access attempts and time to restore operator access separately from customer availability. An illustrative internal objective could require a named responder within 15 minutes of a critical operator lockout; it is neither a vendor SLA nor a promise for every environment. Define severity around the lost operational capability and any customer impact.
The SOP should retain the access path, responsible identity team, diagnostic result, approved change and rollback condition. Escalate when the team cannot establish the intended policy or when recovery requires broader guest access. Review entitlement changes during offboarding rather than waiting for an incident.
Clouvenix can scope Linux administration around documented access and recovery requirements.
Technical reference
Google Cloud: troubleshoot SSH errors. Technical reference reviewed 19 October 2026; confirm prerequisites against your current VM configuration.