7

I edited my Linux Amazon EC2 instance using vim /etc/sudoers and tried adding another account to the list. I realize now that this was a terrible mistake. I can no longer sudo from any account (which means I cannot edit the file again) and I do not have the root account password. Is there anything I can do to correct this?

Thanks.

|improve this question
  • 8
    in future, use visudo (sorry - doesn't help now, i know, but it may avoid a repeat). – andrew cooke May 26 '12 at 18:07
  • is that why this broke? is visudo the way to edit this file? thanks... – Progger May 26 '12 at 18:09
  • it checks for errors and won't let you save if it's broken. it's just an extra safety measure, not a requirement. – andrew cooke May 26 '12 at 18:10
  • 5
    It's worth mentioning that visudo only checks the syntax of the /etc/sudoers file but not the logic. You can still lock yourself out with visudo. Keep a root session open until you have tested your new configuration. – Ladadadada May 26 '12 at 21:09
19

Hopefully you are using an EBS root volume. If so, the solution is not too difficult.

Essentially, you attach the EBS volume to another instance make the changes, and reattach it to the original instance:

  • Stop (don't terminate) the original instance
  • Detach the EBS volume
  • Launch another instance
  • Attach your current EBS volume to the new instance
  • SSH into the new instance, mount the EBS volume and make the needed changes
  • Unmount the EBS volume (e.g. umount -d /dev/xvdh or umount -d /dev/sdh)
  • Detach the EBS volume from new instance and attach it as the root volume (e.g. /dev/sda1) of the old instance
  • Start the old instance
  • If everything is working, terminate the new instance

The reason this works, is that on the fresh, new instance, you have the proper permissions - its root volume is intact - which makes the sudoers file from your original instance just another file you can edit.

If you have an instance-store root volume, unfortunately, you probably won't be able to fix the problem, and will have to revert to an AMI you have made previously as a backup.

|improve this answer
  • 1
    as a recent victim, I have the following to add on: the new instance needs to be in the same zone and security group (and there's no easy way to change these settings for created instances, you'd need to create another until you get it right) – prusswan Jun 21 '12 at 5:04
  • Same zone - definitely - EBS volumes cannot be (directly) attached to instances in other zones (although, you could create a snapshot, and from there a new volume in the same region). The security group though, shouldn't be a factor that prevents you from attaching an EBS volume. By default the security zone allows SSH access, and the keypair used is stored on the root volume of the new instance (so doesn't need to match the pre-existing instance either). – cyberx86 Jun 21 '12 at 9:20
  • Thanks, this definitely did the trick. One thing I had a bit of trouble with was getting the right root volume name when re-attaching to the original VM. The first step here ought to be "take note of the root volume's device e.g. /dev/xvda" so it can be used later when re-attaching. – Christopher Schultz Oct 20 '15 at 0:22
  • Important note here would be that the sudoers file must have 0400 permission. In my case I could not edit the original, so I gad to rename it and create new one, only the new one didnt have right permissions, so had to go through all the stuff again – Tomas Mar 3 '16 at 12:00
2

It depends whether it's an AMI or EBS root device.

If it's an AMI and you don't have the root password, and the AMI doesn't configure root SSH access, then there's nothing you can do.

If it's an EBS root you can terminate it and attach the volume to a different instance (as an additional disk, not the root). You can then either access the data, or correct the sudoers file and launch a new instance using the volume.

|improve this answer
0

even if instance-store is root volume, you can just attach this root volume as a secondary volume in another instance(like /dev/xvdh) and mount it to some folder and make the changes in sudoers.

|improve this answer
0

Here is what I did To solve this Problem-

  1. Launched a same Hardware Like (the one that was messed up) instance.
  2. Stop the messed up instance.
  3. ssh the complete ubuntu folder (Which had all the files needed).
  4. Started the replica Server and ensured that everything worked fine.(We use Mongo, Mysql, Tomcat, and Java).
  5. Once done I detached the elastic IP used for the messed up instance and attached to the replica instance.

Voila Now you have a new running instance with the same config and IP.

Time taken 30 mins.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.