Reputation: 2218
I was able to connect to my VM correctly before. I closed the SSH window and reconnected, it now just loop between "transferring SSH keys to VM" and "connecting to SSH". This is in the console:
[19864.873131] google_accounts_daemon[720]: Adding user gurvanbk to group google-sudoers
Mar 26 19:07:01 winter-lounge google_accounts_daemon[720]: Adding user gurvanbk to group google-sudoers
Mar 26 19:07:41 winter-lounge google-accounts: INFO Adding user gurvanbk to the Google sudoers group.
It keeps looping that log. Also here is another post I made on ServerFault.
nmap result:
PS C:\WINDOWS\system32> nmap XX.XX.XXX.XXX
Starting Nmap 7.80 ( https://nmap.org ) at 2020-03-28 12:48 Paris, Madrid
Nmap scan report for 245.151.90.34.bc.googleusercontent.com (34.90.151.245)
Host is up (0.027s latency).
Not shown: 998 filtered ports
PORT STATE SERVICE
22/tcp open ssh
3389/tcp closed ms-wbt-server
Nmap done: 1 IP address (1 host up) scanned in 9.17 seconds
Upvotes: 0
Views: 553
Reputation: 409
That log of google_accounts_daemon on the serial console is not an ssh or sudoer issue, it looks more like a network one. Following this guide:
So we manage to see this port is open. Now verify again GCP firewall rules (gcloud compute firewall-rules list), if you don't see 22 fw rule you can create it (gcloud compute firewall-rules create default-allow-ssh --allow tcp:22).
Then if all network setup it's ok, try to delete all SSH keys from VM instance metadata and from Compute engine metadata and stop and start your VM Instance, this will force google to create new ssh keys and push them to the vm instance, finally try to connect again.
If this last method don't work, delete again all ssh keys from Compute Engine metadata and VM instance metadata. Then enable OS login feature to try other method of ssh keys injection to your VM instance, once it is activated, stop and start the instance and try to connect again.
Upvotes: 1