google cloud compute engine: cannot connect with ssh even from within browser

2
votes

I am trying to connect to a VM Instance in Google Cloud Compute Engine, using the ssh button in the web browser. I was able to do it before, but today it opens a window and endlessly tries to connect, switching back and forth to a message:

The key transfer to project metadata is taking an unusually long time. Transferring instead to instance metadata may be faster, but will transfer the keys only to this VM. If you wish to SSH into other VMs from this VM, you will need to transfer the keys accordingly.

I look at the ssh troubleshooting guide, although it is not clear to me which steps refer to connexion from within the browser, or from a third-part ssh client. I can confirm that:

  1. It is not a full disk issue
  2. My firewall enables ssh: gcloud compute firewall-rules list returns default-allow-ssh default INGRESS 65534 tcp:22 False

  3. Network connexion somehow works: nmap [IP] returns a error Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn but using nmap -Pn [IP] returns: Host is up (0.021s latency). Not shown: 998 filtered ports PORT STATE SERVICE 22/tcp open ssh 3389/tcp closed ms-wbt-server

  4. I also tried the startup script, but didn't get much from it, due to an error: Could not download http://storage.googleapis.com/gce-scripts/gee.sh. HTTP Error 500: (which I filed as a github issue)

What else can I do to troubleshoot? I assume that not being able to connect through ssh from with in the browser indicates that the problem is on the VM, not on my local computer? Is this correct?

Thanks!

2
sshgoogle-cloud-platformgoogle-compute-enginessh-keys
Please move your question to Super User (delete here, re-post there). It's off-topic here. – Martin Prikryl
Ok, I flagged it for closing and migrating, is that the correct approach? – Matifou

2 Answers

1
votes

To troubleshoot this, you can enable interactive access, connect to the instance through the serial console and enter the serial port access information to access the disk, review the ssh config files $ sudo vi /etc/ssh/sshd_config and $ sudo vi /etc/ssh/ssh_config.

If you don’t have a root password for the serial console, you could use a startup script to add it to your instance as follows:

  1. Go to the VM instances page in Google Cloud Platform console.
  2. Click on the instance for which you want to add a startup script.
  3. Click the Edit button at the top of the page.
  4. Click on ‘Enable connecting to serial ports’
  5. Under Custom metadata, click Add item.
  6. Set 'Key' to 'startup-script' and set 'Value' to this script:

Example of script:

#! /bin/bash 
useradd -G sudo user1
echo 'user1:pass@user1' | chpasswd
  1. Click Save and then click RESET at the top of the page. You might need to wait for some time for the instance to reboot.
  2. Click on 'Connect to serial port' on the page.
  3. In the new window, you might need to wait a bit and press the Enter of your keyboard once; then, you should see the login prompt.
  4. Login using the USERNAME and PASSWORD you provided. Example: Username: user1 AND Password: pass@user1

You can also review the serial-port logs of the affected instance for possible clue on the issue. If you have a snapshot of your instance disk, you can create a new VM. As per the issue, is possible that recent changes may have affected the instance boot sequence and the sshd_config file.

0
votes

As you have the access of the sshd_config file, so you can configure ssh as per your requirement.

Warning message: When you click on the SSH button or SSH from gcloud within the Console, GCE will create a public/private key pair on your behalf. These keys that are added to the metadata have an expiry date. When the keys are added, the accounts daemon adds these SSH keys to the authorized keys file. When these keys expire, the accounts daemon on the VM instance realizes that there is no longer any metadata associated with the Google-managed user account and deletes the authorized key file.

I have attached a Github link that shows how the Google compute engine accounts daemon behaves.

You can manage your own key files by generating your own keys that do not expire by following the step by step instructions; however, I would suggest reading the "Risk of manual key management" section of the article before you decide if you would want to manage your own keys.

You can see the serial port logs from here.

Can you please elaborate the HTTP Error 500 issue? -where are you getting this message/error?