Last changed: 2024-02-21
There can be multiple reasons for losing access to an instance.
Lost SSH key
Disk trouble e.g. wrong mount path (Rescue instance)
Problems with NIC/network (Rescue 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.
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.
curl -o pub.keys https://github.com/username.keys
Then add or replace the keys in authorized_keys
cat username.keys >> authorized_keys
The authorized_keys file is located in
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.
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
If you need to edit security groups then edit instance and then select “Security Groups”.
THIS IS RELATED to LINUX!
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.