Especially when you lost ssh access to your virtual server (e.g. due to errors in ~/.ssh/authorized_keys, /etc/sudoers, /etc/group, /etc/shadow or another important config file).
When you catch errors like:
No supported authentication methods available
or
sudo
sudo: >>> /etc/sudoers: syntax error near line 1 <<<
sudo: parse error in /etc/sudoers near line 1
sudo: no valid sudoers sources found, quitting
sudo: unable to initialize policy plugin
Don't worry, inside the Amazon cloud you can repair almost all.
Follow these simple steps to solve the problem:
- Via AWS console:
- Launch new temporary EC2 micro-instance in the same availability zone.
- Stop broken instance.
- Detach root EBS volume from the broken instance.
- Attach this EBS to the temporary instance (as /dev/sdf).
- Via SSH console from the temporary instance:
- Mount this EBS:
sudo mount /dev/xvdf /mnt - Fix all problems on mounted file system.
- Unmount this EBS:
sudo umount /mnt - Via AWS console:
- Detach this EBS from the temporary instance.
- Attach this EBS to the broken instance (as /dev/sda1).
- Start broken instance.
- Check that broken instance now is healthy (available via ssh and everything is functioning normally).
- Then you can stop temporary instance (or terminate it).
Saved my bacon. It silly that I ended up here (who woulda thunk that a simply yum update would render my AWS free tier RHEL server unbootable?? Oh yeah, custom kernels for AWS...) but I did end up needing these exact steps. Thanks for posting these up
ReplyDelete+1 very helpful. Was kind of surprised there was no java console (not via ssh) or a way to access a virtual serial port via CLI or web UI. Thanks for sharing.
ReplyDeleteExcellent process that helped me.
ReplyDeletecan you please explain how to do the step
ReplyDelete1.4 Attach this EBS to the temporary instance
Gracias Amigo me sirvi´!!
ReplyDelete