0

A bit of stupidity. On my Google Compute Engine (GCE) instance, I went in and changed the sshd_config to listen another port (something I do routinely)...but I didn't test before logging off. And there's a typo. So now I can't log in via ssh because the config is screwed up and sshd won't even start. (I can launch sshd with a different config file, as a non-root user, but it gives me a "Could not load host key", as expected, probably doesn't have the permissions.)

Use the GCE serial console you say? Ah... but none of the users I can login with are sudoers. (I have two others with sudo'er, but the passwords aren't working, don't know why. I wrote them down wrong?)

So I have user (non-root) access with password, and have keys for root (sudo'er) users, I just don't have a way to log in with those thru the serial console? (Is there a way to have the console recognize my keys instead of a password?)

It's good for security that I can't just fix this in 5 minutes with my limited knownledge, but can I leverage what I have to get back in with root? I have the access to the project in the Google Compute Engine Console and the users, etc., I just have cut myself off from command line on this instance.

If it were a physical machine, I'd stick in bootable usb distro and simply edit config file and restart.

Any suggestions?

Thanks.

Improve this question
4
  • 2
    If you have console access, you should be able to boot the system into single user mode and correct the ssh configuration.
    – larsks
    Commented Nov 2, 2016 at 0:35
  • Great suggestion larsks, thank you. I know how to do this on a physical machine. As noted, this is about a Google Cloud Engine instance, so where/how do you do that for an instance in GCE? I've Googled, but I can't find that anywhere.
    – codenoob
    Commented Nov 3, 2016 at 0:08
  • I'm not actually certain (I'm not a GCE user), but you said that you had access to a serial console, in which case the process should be the same as for a physical machine: while connected to the console, reboot the machine, and then see if it's possible to interrupt the bootloader.
    – larsks
    Commented Nov 3, 2016 at 1:06
  • There is some documentation here
    – larsks
    Commented Nov 3, 2016 at 1:07

1 Answer 1

Reset to default
2

To edit or examine configuration files in the root disk of a VM that you do not have access, follow the steps in the section ¨Inspect an instance without shutting it down¨ of this document.

A summary of the steps:

1) Create a temporal VM you can SSH into.

2) Create a copy of the root disk that is failing (this would have to be from a snapshot). You can actually delete the original VM and keep the disks (-keep-disks=all) but I would rather work with a copy.

3) Attach the copy of the disk to the temporal VM and mount the disk you wish to examine.

4) Modify the config files. Detach the modified disk and spin a new VM using this disk.

Improve this answer
2
  • Thanks Carlos. Seemed like a lot of work when I thought about it, and wasn't sure it would work. With your guidance and knowledge that it would work in the end, was not so hard. I guess if there were a way to change the file directly, that would represent a security issue.
    – codenoob
    Commented Nov 11, 2016 at 19:27
  • I am glad it worked. I believe the serial console approach would have worked if you had been able to log with a sudoer.
    – Carlos
    Commented Nov 14, 2016 at 15:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .