Google Cloud VM SSH No supported authentication methods available

user_1365460 0
Viewed 430

I have a Google cloud VM instance with Debian OS. I have hosted Wordpress sites. After upgrading OS version all was working fine and I was able to connect via SSH using 'Open SSH in browser' option.

Now I try to connect my VM instance using 'Open SSH in browser' it just keep retrying. I checked the serial console output but there is no error message. Please refer below enter image description here

However, I am able to connect via FTP using same key but when I try to connect via SSH at that time facing the issue. I checked for port 22 for that instance and project and it's open enter image description here

Below is the Last few lines of serial console log after I restarted the VM,

Dec  6 09:01:20 localhost sendmail[383]: Starting Mail Transport Agent (MTA): sendmail.
Dec  6 09:01:20 localhost systemd[1]: Started LSB: powerful, efficient, and scalable Mail Transport Agent.
Dec  6 09:01:21 localhost systemd[1]: Started MariaDB 10.3.31 database server.
Dec  6 09:01:21 localhost systemd[1]: Reached target Multi-User System.
Dec  6 09:01:21 localhost systemd[1]: Reached target Graphical InterfacDec  6 09:01:21 localhost systemd[1]: Startup finished in 4.063s (kernel) + 9.852s (userspace) = 13.915s.
Dec  6 09:01:21 localhost /etc/mysql/debian-start[567]: Upgrading MySQL tables if necessary.
Dec  6 09:01:21 localhost /etc/mysql/debian-start[570]: /usr/bin/mysql_upgrade: the '--basedir' option is always ignored
Dec  6 09:01:21 localhost /etc/mysql/debian-start[570]: Looking for 'mysql' as: /usr/bin/mysql
Dec  6 09:01:21 localhost /etc/mysql/debian-start[570]: Looking for 'mysqlcheck' as: /usr/bin/mysqlcheck
Dec  6 09:01:21 localhost /etc/mysql/debian-start[570]: Version check failed. Got the following error when calling the 'mysql' command line client
Dec  6 09:01:21 localhost /etc/mysql/debian-start[570]: ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: NO)
Dec  6 09:01:21 localhost /etc/mysql/debian-start[570]: FATAL ERROR: Upgrade failed
Dec  6 09:01:21 localhost /etc/mysql/debian-start[580]: Checking for insecure root accounts.
Dec  6 09:01:21 localhost debian-start[564]: ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: NO)

Debian GNU/Linux 10 localhost ttyS0

localhost login: Dec  6 09:01:28 localhost systemd[1]: Stopping User Manager for UID 110...
Dec  6 09:01:28 localhost systemd[497]: Stopped target Default.
Dec  6 09:01:28 localhost systemd[497]: Stopped target Basic System.
Dec  6 09:01:28 localhost systemd[497]: Stopped target Timers.
Dec  6 09:01:28 localhost systemd[497]: Stopped target Paths.
Dec  6 09:01:28 localhost systemd[497]: Stopped target Sockets.
Dec  6 09:01:28 localhost systemd[497]: gpg-agent-browser.socket: Succeeded.
Dec  6 09:01:28 localhost systemd[497]: Closed GnuPG cryptographic agent and passphrase cache (access for web browsers).
Dec  6 09:01:28 localhost systemd[497]: dirmngr.socket: Succeeded.
Dec  6 09:01:28 localhost systemd[497]: Closed GnuPG network certificate management daemon.
Dec  6 09:01:28 localhost systemd[497]: gpg-agent-ssh.socket: Succeeded.
Dec  6 09:01:28 localhost systemd[497]: Closed GnuPG cryptographic agent (ssh-agent emulation).
Dec  6 09:01:28 localhost systemd[497]: gpg-agent.socket: Succeeded.
Dec  6 09:01:28 localhost systemd[497]: Closed GnuPG cryptographic agent and passphrase cache.
Dec  6 09:01:28 localhost systemd[497]: gpg-agent-extra.socket: Succeeded.
Dec  6 09:01:28 localhost systemd[497]: Closed GnuPG cryptographic agent and passphrase cache (restricted).
Dec  6 09:01:28 localhost systemd[497]: Reached target Shutdown.
Dec  6 09:01:28 localhost systemd[497]: systemd-exit.service: Succeeded.
Dec  6 09:01:28 localhost systemd[497]: Started Exit the Session.
Dec  6 09:01:28 localhost systemd[497]: Reached target Exit the Session.
Dec  6 09:01:28 localhost systemd[1]: user@110.service: Succeeded.
Dec  6 09:01:28 localhost systemd[1]: Stopped User Manager for UID 110.
Dec  6 09:01:28 localhost systemd[1]: Stopping User Runtime Directory /run/user/110...
Dec  6 09:01:28 localhost systemd[1]: run-user-110.mount: Succeeded.
Dec  6 09:01:28 localhost systemd[1]: user-runtime-dir@110.service: Succeeded.
Dec  6 09:01:28 localhost systemd[1]: Stopped User Runtime Directory /run/user/110.
Dec  6 09:01:28 localhost systemd[1]: Removed slice User Slice of UID 110.

Tried following solutions which I get from google search

Solution 1 : Using PuTTYGen & Putty

Generated key using PuttyGen and put the public key under meta data as well tried adding under instance. I have set enable-oslogin to FALSE. But got the following error message. enter image description here

Solution 2 : Using serial ports

When I tried to connect using diff serial ports it just stack at connection screen and I checked the console log for that serial port but it's blank. enter image description here

Solution 3 : New Instance with disk image

Created image of current disk and then created new instance with that image. When I try to connect to that new instance then I am facing same issue.

Solution 4 : Use diff machine to setup CLI

I setup fresh Google Cloud CLI into a new machine and tried to connect but no success. Same error I faced.

Solution 5 : Increase Disk Space

Increased the disk space from 20GB to 35GB, but didn't work. Usually if there is disk space error the we get it into serial console log. But in my case there is no error message in serial console log.

Please help and let me know if any additional information is required. Thanks

google-cloud-sdk google-compute-engine google-cloud-platform ssh
1 Answers

Please follow some of the troubleshooting steps while starting SSH in browser :

  1. Wait a few minutes and try again. It is possible that:

  • The instance has not finished starting up.

  • Metadata for SSH keys has not finished being propagated to the
    project or instance.

  • The Google Agent has not yet read the SSH keys metadata

  1. Verify that SSH access to the instance is not blocked by a firewall.

  2. Make sure that the root volume is not out of disk space.

  3. Verify that the user attempting to SSH has the compute instance admin role or the service account user role (if the instance is set up to run as a service account). These roles are needed to update the instance's or project's SSH keys-metadata.

  4. Verify that temporary SSH Keys metadata is set for either the project or instance.

  5. Verify that the Linux Google Agent scripts are installed and running.If the Linux Google Agent is not installed, reinstall it.

  6. Verify google-guest-agent.service is enabled and started. These may need to be executed in the serial console.

           systemctl status google-guest-agent.service

If the service is disabled, enable and start the service

   systemctl enable google-guest-agent.service
   systemctl start google-guest-agent.service

8.Verify that there is a default route to the Internet (or to the bastion host).

Some network configurations can prevent SSH from the browser from working correctly. SSH from the browser might not work correctly if HTTPS proxies or security devices interfere with traffic sent to Google APIs and services. If SSH from the browser isn't working, check that the network used by the system using SSH from the browser meets these requirements:

  • HTTPS proxies and security devices must not decrypt and re-encrypt traffic using their own TLS certificate, for example, to perform TLS inspection.
  • The system's network must allow traffic to and from hostnames ending in google.com, gstatic.com, or googleapis.com.
  • The system's network must allow packets to be sent to the IP addresses for the default domains.

Check the doc for troubleshooting ssh.

#6. Please check the following document to install Linux Guest Agent.

#8 Checking Routes:

SSH needs a way to communicate back on the connection.Sometimes the default route to the Internet is deleted out of security concerns or otherwise misconfigured it in a way which would deny egress from the affected machine.

  • First look in VPC Network > Routes, then filter by the VPC network that is used by the instance.

  • The system-generated default route has a description "Default route to the Internet.", destination of 0.0.0.0/0, priority of 1000 and "Default internet gateway" as next hop.

  • If you are using a bastion host, then there should be a route going to the bastion host in the same network.Verify that there is connectivity using e.g. telnet [host-ip] 22 (assuming SSH on the [host-ip] runs on port 22). This should be presented with the SSH banner. (Press Ctrl+] and then quit to exit telnet.)

  • You can also use the gcloud tool to list routes. For e.g.

    gcloud compute routes list --filter="network=" | grep "default-internet-gateway"

user_157451060
Related