Score:0

Increased my VM disk size on Google Cloud Platform and now the SSH log in is asking for a password?

in flag

I increased the disk size on my VM instance running on Google Cloud Platform. There was a simple change from 200 GB to 400 GB with no other changes made on the Instance. When I started the instance after making the changes and trying to login through my passwordless private SSH keys on PuTTY, the server refused my keys and I can't open SSH through the browser either (It just says connecting and then couldn't connect, retrying).

Since then, I have reset the keys, generated new public and private keys, checked my firewall, OS-login and even ran some troubleshooting scripts all of which lead to nothing. After setting enable-oslogin as true once though PuTTY has been asking me for a password to login through my SSH key and I have never set any password at all? I have set the oslogin to false and even removed it from my metadata but it still asks for a password that I have not set.

If anyone has any clue about what might be going on I would be greatly helped. Thank you very much.

John Hanley avatar
cn flag
Enable the Compute Engine serial console and review the startup/boot logs to determine why your SSH keypair is not being accepted.
Score:0
fr flag

Is this disk you upgraded the OS drive or another drive? If it is your OS volume, then maybe the permissions of /home/${USER}/.ssh/authorized_keys got changed. If these permissions get messed up, then you can't SSH using public keys, and you have to temporarily turn on password auth in /etc/ssh/sshd_config to log in and change the permissions. There is not much you can do once you are locked out, but if there's any way to log back in, follow these steps to restore permissions so you can get SSH working again. Also, this assumes that you have your SSH keys in /home/${USER}/.ssh.

For SSH to work, the /home directory needs to be owned by root with a 755 mask:

chown root:root /home
chmod 755 /home

The /home/${USER} directory needs to be owned by ${USER} and have the permissions 700.

chown ${USER}:${USER} /home/${USER}
chmod 700 /home/${USER}

The /home/${USER}/.ssh directory needs to be owned by ${USER} with permissions 700.

chown ${USER}:${USER} /home/${USER}/.ssh
chmod 700 /home/${USER}/.ssh

Finally, the file /home/${USER}/.ssh/authorized_keys file has to be owned by ${USER} and have the permissions 600

chown ${USER}:${USER} /home/${USER}/.ssh/authorized_keys
chmod 600 /home/${USER}/.ssh/authorized_keys

Finally, try SSH'ing in to your instance:

ssh -i /path/to/pub/key ${USER}@${IP_ADDRESS}

This is what saved me when I accidentally messed up permissions for my AWS instance. Here's what I found online regarding your issue:

https://cloud.google.com/compute/docs/troubleshooting/troubleshooting-ssh https://cloud.google.com/compute/docs/troubleshooting/troubleshoot-os-login

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.