Guide: Rescue and Recovery

Restore Access to VM

In some cases, you may lose access to a running virtual machine (VM) — for example, if your SSH key is missing. This guide explains how to recover your data or restore access to the instance.

⚠️ Note: The steps described below are emergency recovery procedures. These procedures are meant for recovery and troubleshooting. To avoid this situation, always store and manage your SSH keys securely.

Before proceeding, make sure the issue is not caused by network problems (for example, a misconfigured security group, missing SSH rule, or a changed floating IP). If you have confirmed that the VM is otherwise reachable and the issue is related to SSH access, you can use one of the recovery methods below. These steps can be carried out via the Dashboard or the CLI.

Choose the Recovery Method

There are two different recovery goals:

• Recover data from the original disk: Use the volume-based recovery method described in Recovery via helper VM.
• Restore login access to a VM: Use Rebuild from snapshot.

The methods are not equivalent:

• The helper-VM method works even if the guest operating system no longer boots correctly, SSH is misconfigured, or key injection does not work.
• Rebuild-from-snapshot depends on the guest image supporting SSH key injection, typically via cloud-init. OpenStack documents this as a requirement for successful key injection.

Rebuild from snapshot

This method can be used to restore access more quickly if the guest image supports key injection during instance launch.

Procedure

1. Stop the affected VM.
2. Create a snapshot of the instance.
3. Launch a new instance from that snapshot.
4. Select a new working key pair during instance creation.
5. Start the instance and test SSH access.

Important limitation

This method depends on the image inside the VM supporting key injection, usually through cloud-init. OpenStack states that, for a key pair to be injected successfully, the image must contain cloud-init.

If the guest does not process the new metadata correctly, the instance may boot successfully but still remain inaccessible via SSH. In that case, use the helper-VM method instead.

Recovery via helper VM

This method is the most robust option for data recovery and for manually repairing SSH access on the original disk.

Procedure

1. Stop the affected VM (for example, foo1_vm).
2. Create a snapshot image of the instance and name it (for example, foo1_img).
3. Create a new volume from foo1_img (for example, foo1_vol).
4. Launch a fresh helper VM (for example, foo2_vm) using a known working key pair.
5. Attach foo1_vol to foo2_vm.
6. Log in to foo2_vm and mount the attached volume. The mounted file system contains the original VM's disk contents.

At this point, you can:

• recover user data from the mounted file system, or
• repair access by editing the original VM's SSH configuration on disk.

Optionally: Repair SSH access on the original disk

After mounting the original disk on the helper VM:

1. Locate the affected user's home directory.
2. Open the file ~/.ssh/authorized_keys on the mounted disk.
3. Add a new SSH public key.
4. Check file permissions, for example:
   • ~/.ssh should usually be 700
   • authorized_keys should usually be 600
5. Detach the volume from the helper VM.
6. Boot a replacement instance from the repaired volume, or rebuild the original setup as needed.

Note: This method does not rely on OpenStack injecting a new key into the guest. It works even if the VM itself is no longer accessible by normal means.

Recommendation

• Use helper-VM recovery if you primarily want a reliable way to access the original disk or if the VM may be broken beyond SSH alone.
• Use rebuild from snapshot only if you expect the guest image to handle a newly assigned key correctly.