Last changed: 2024-02-21

Lost access to instance

There can be multiple reasons for losing access to an instance.

Don’t fret, there is maybe a way (workaround) to fix this by accsessing the console/terminal. But you need to do some “hacks” to do so if you didn’t set/change a users password.

Possible solution (workaround [1])

Got to console, press the “Send ctrlAltDel” button then activate the console window and interrupt the boot by pressing an arrow key for example. Choose a boot entry and press e for edit. Depending on which OS is in use you can edit the boot loader in the console and boot to single user by adding single to the end of the line that start with linux on ubuntu, on centos you have to remove all console=ttys besides the tty0 and add rd.break enforcing=0 at the end of the line starting with linux16. There a several exampels and documentation on how to start your Linux server/instance in singel mode (root access) which you can find by searching the web. On centos you have to be fast to interrupt the normal boot. Depending on if you are using Ubuntu or Centos you should now have a console and logged in as root. The keyboard layout is probably en_US.UTF8 which means you have to figure out what keys on your keyboard represent =, /, - and : etc.

On my keyboard (norwegian):

= is \ left key from backspace

/ is - left key from right shift

- is ? second left key from backspace

: is shift + ø

Now you can issue a password change for e.g. the root account by running passwd or passwd username. If you are using Centos you have to do some additional steps as follows. You need to mount /sysroot by running mount -o remount,rw /sysroot and then change root by running chroot /sysroot. Now you can run e.g passwd After you’ve don that, reboot and log in to console again on normal boot. Now you can fix the authorized_keys. I fetched my public ssh keys from github.

E.g wget or curl -o pub.keys

Then add or replace the keys in authorized_keys

E.g cat username.keys >> authorized_keys

The authorized_keys file is located in /home/username/.ssh/authorized_keys Now you should be able to login using ssh with the new key(s).


If you are experiencing problem with booting up and you have attached volumes(s), try dettach them first then run rescue agian.

Rescue instance

Here is a quick runddown on how it is done using the dashboard.

For more information, take a look at the Openstack documentation on rescue mode


Setting a password when activating rescue mode dose not work. If you lost access to the SSH key take a look at lostaccess

Start rescue mode form dashboard Start rescue mode form dashboard Start rescue mode form dashboard

If you need to edit security groups then edit instance and then select “Security Groups”.

Start rescue mode form dashboard Unrescue instance form dashboard



If you do not select a specific image (or specify the same as the instance originally used, which in effect is the same), the two (pseudo)disks may end up with the same UUID. For some distributions this may cause the instance to mount its root filesystem from the damaged disk. The upshot is that any SSH connections will seemingly connect to the broken instance, and the rescue attempt is thus moot.

The workaround is to explicitly specify an image for the rescue attempt, and select any other image than the one used for setting up the instance in the first place.