3

I'm using Debian on a headless server that I'm connecting to via ssh.

When I installed Debian, I did not create a root account, so the first user created was in the sudo group. Then I added that user to another group, but in my ignorance I used:

sudo usermod -G NewGroup UserName

instead of:

sudo usermod -aG NewGroup UserName

Without the 'a' (append), this removed the user from every group (including sudo) other than the default UserName group.

I've learned my lesson now, but is there any way to regain superuser access to this installation?

This is a test environment with nothing to backup or recover, so I can simply reformat if all is lost, but I thought I'd ask anyway.

  • You could setup a rescue disk image, add it to your VM to boot from, and from there proceed with your corrections. – Julie Pelletier Aug 30 '16 at 3:55
  • 1
    Is the server physically accessible by you? If so you can create a live medium with ssh-access enabled, then go on to manipulate your /etc/group file. – Fiximan Aug 30 '16 at 11:22
  • Thank you for the suggestions. The server is physically accessible. I can create a live usb, but will have to attach a monitor and keyboard to get it started anyway, right? (At least to get the computer to boot from USB) Or am I confused about what you mean? – LvxOne Aug 30 '16 at 16:44
  • You have the root password, and access to the console? Log in as root and edit the /etc/group file appropriately. Or is this the bit you're unsure about? – roaima Aug 30 '16 at 23:43
  • 1
    @Fiximan This was edited and reopened; can you post your solution as an answer below? – Michael Mrozek Aug 31 '16 at 20:10
1

Assuming you have physical access to the server, you can either create a live medium which has a headless boot routine including an ssh-server to be started and then access the server via these ssh-credentials or - the simpler approach - in case you have a monitor and a keyboard available, plug them in and simply boot into the system.

Then mount the original hard drive and edit the /etc/group file accordingly (i.e.: sudo:x:<integer_number>:<username>).

As a hint for the future: IMHO having an active root account (i.e. password is not locked) is not necessarily a security risk - especially if you restrict ssh-access for root.

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.