Can't access VM Instance through SSH

Viewed 98

I was connected to the VM instance through SSH and by mistake I ran the following command:

"chmod -R 755 /usr"

And then I started getting the following message:

"/usr/bin/sudo must be owned by uid 0 and have the setuid bit set"

I have read different solutions for it:

  1. Setting a startup-script to change root password and connect through

gcloud beta compute ssh servername

However, I can't stop my instance because I have a local SSD assigned to it, so I don't think the startup-script will work and connecting through ssh asks me for a password:

user@compute.3353656325014536575's password:

But I have never set a password for the user I am using.

Is there any solution so I can connect again to the server and fix the mistake?

Edit: I have a user which I created manually for an FTP, however this one doesn't have sudo permissions, is there a way to know the sudo password?

Thanks in advance.

1 Answers

From the issue at hand the command chimed-R 755 will give everybody root permission Try this first before reading other steps down. Ssh into your instance. To change password Just type Sudo passwd Type new password And confirm new password.
If that doesn't work, Follow the steps below

"/usr/bin/sudo must be owned by uid 0 and have the setuid bit set"

This means the sudo root permission has been over written, which creates restriction of using sudo and it leads you into problems like all the root access you lost. The following steps should help resolve the issue

create a backup or snapshot of your instance

Create a totally new instance and detach your local ssd from the last instance attach, it back to the newly created instance.

Login to new instance and create a new folder in the root, and start operation as root.

check the attached drive in new instance : “mount”…… “fdisk -l | grep Disk”.

Create new folder in root directory : “mkdir /newfolder”

Now mount the vol : “sudo mount /dev/xvdf1 /newfolder/”

After mount if you check the permission you will see that the newfolder permission got changed after mounting because of the effected volume:

Related