# Recovering SSH access to a Hetzner GPU server with Rescue

Recover a Hetzner dedicated GPU server through Robot and Rescue System by separating panel access, OS diagnosis and a minimal reversible repair.

Author: Retrivium team
Updated: 2026-11-01
Canonical URL: https://retrivium.ai/journal/hetzner-gex-root-rescue-access/
Language: en

If SSH access to a Hetzner dedicated GPU server is lost, use the documented Robot and Rescue System route for diagnosis. Rescue boots a separate network environment that can inspect the installed system. Begin by identifying the cause rather than reinstalling the server immediately.

## Separate Robot from the installed OS

Robot controls the server at the provider level, while normal SSH enters its operating system. A broken key, firewall rule or OS update does not necessarily mean panel access is lost.

Follow the dedicated-server Rescue instructions for activation and reboot. Similar cloud-VM features can use a different panel and procedure. Before rebooting, determine whether important work is still running and what results have been saved. Switching the boot environment does not preserve the old compute process.

## Preserve the symptoms

Record the last successful login and changes before the failure: an update, SSH configuration edit, key replacement or network rule. Distinguish routing, a listening service and authentication errors.

If another authorised management route exists, use it to inspect the situation. Keep the diagnostic procedure available outside the affected server. A recovery guide stored only inside the unreachable environment is not a useful dependency.

## Inspect the correct disk in Rescue

Confirm the visible devices and filesystem layout before changing anything. Do not format or install as part of the first diagnostic step. Start with cautious inspection and preserve valuable data.

| Suspected cause | Area to inspect |
| --- | --- |
| SSH configuration | Changed settings and OS logs |
| Wrong key | Intended user's authorized_keys |
| Network restriction | Installed-system rules |
| Full storage | Free space and large logs |
| Failed normal boot | OS configuration and available logs |

Commands depend on the layout and installed system. Confirm whether a path belongs to Rescue or the mounted installed OS; editing the wrong environment can leave the actual problem untouched.

## Repair minimally and retest

For an accidental firewall lockout, preserve the changed file, correct the specific cause through the documented route and return to normal boot. Open a fresh successful SSH session before closing the remaining recovery path.

Record the cause and successful fix for the next operator. Keep Robot access responsibility, backup verification and restart authority clear. A reproducible repair and known remote recovery channel are practical parts of a usable GPU server, not incidental details after choosing its VRAM capacity.

## Turn the check into a practical next step

Rescue is a separate diagnostic boot environment. Identify the affected disk and cause before writing changes, and verify normal access after the repair.

For the documented details, consult the [primary documentation](https://docs.hetzner.com/robot/dedicated-server/troubleshooting/hetzner-rescue-system/); [configuration reference](https://docs.hetzner.com/robot/dedicated-server/server-lines/gpu-server/). Continue with [hetzner gpu vps vs gex](/journal/hetzner-gpu-vps-vs-gex/) and [cloud gpu resource cleanup audit](/journal/cloud-gpu-resource-cleanup-audit/).