8

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
4
  • 9
    in future, use visudo (sorry - doesn't help now, i know, but it may avoid a repeat).
    – andrew cooke
    May 26, 2012 at 18:07
  • is that why this broke? is visudo the way to edit this file? thanks...
    – Progger
    May 26, 2012 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, 2012 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, 2012 at 21:09

6 Answers 6

Reset to default
20

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
5
  • 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, 2012 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, 2012 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, 2015 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, 2016 at 12:00
  • Thank you! This was simple and worked great for me.
    – Amon
    Mar 20, 2022 at 11:01
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
0

Official instructions for fixing this are here: https://aws.amazon.com/premiumsupport/knowledge-center/ec2-sudo-commands/

Improve this answer
0

While this post is old, this issue recently came up and below is a solution if you know part of the line that caused the issue. If it fits your needs, this will save you from needing to unmount the partition and mount to another partition and then alter the file and then reverse the process.

Source: https://aws.amazon.com/premiumsupport/knowledge-center/ec2-sudo-commands/

This works on:

  • Red Hat-based distributions such as SUSE, CentOS, Amazon Linux 1, Amazon Linux 2, and RHEL.
  • Debian-based distributions (such as Ubuntu).

Steps:

  1. Stop the instance
  2. Once stopped, go to Actions -> Instance Settings -> Edit user data
  3. Paste in the following code (no whitespace before or after). The last two lines add a file so you know it worked, even if there is an issue with the sudoers change, and it also will remove any line in /etc/sudoers containing the string "string-unique-to-line" Start the instance You should now be able to run sudo visudo this time so you don't corrupt the file again
    Content-Type: multipart/mixed; boundary="//"
    MIME-Version: 1.0
    
    --//
    Content-Type: text/cloud-config; charset="us-ascii"
    MIME-Version: 1.0
    Content-Transfer-Encoding: 7bit
    Content-Disposition: attachment; filename="cloud-config.txt"
    
    #cloud-config
    cloud_final_modules:
    - [scripts-user, always]
    
    --//
    Content-Type: text/x-shellscript; charset="us-ascii"
    MIME-Version: 1.0
    Content-Transfer-Encoding: 7bit
    Content-Disposition: attachment; filename="userdata.txt"
    
    #!/bin/bash
    /bin/echo "Hello World" >> /tmp/testfile.txt
    sed -i '/string-unique-to-line/d' /etc/sudoers
    --//--
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.