Unable to ssh via cloud shell terminal

[MIRSK Development]

I just created a new VM and are using the cloud shell terminal to access the machine for the first time.

I usually run the predefined command line offered by google and have no issues with that, until now. Running that command returns after a while:

ssh: connect to host XX.XX.XX.XX port 22: Connection timed outERROR: (gcloud.beta.compute.ssh) [/usr/bin/ssh] exited with return code [255].

I guess this is a problem with the port not being opened in the firewall, but this has not been a problem in the past.

The only difference now is that this machine is located in us-central1-a rather than where we usually put our machines. Can this be the problem?

[momo cloud9]

Hi MIRSK,

From where you are trying to connect 

Regards,

momo

--
© 2018 Google Inc. 1600 Amphitheatre Parkway, Mountain View, CA 94043
 
Email preferences: You received this email because you signed up for the Google Compute Engine Discussion Google Group (gce-dis...@googlegroups.com) to participate in discussions with other members of the Google Compute Engine community and the Google Compute Engine Team.
---
You received this message because you are subscribed to the Google Groups "gce-discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gce-discussio...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gce-discussion/4df58ce2-2857-4a07-837a-8c418e67add9n%40googlegroups.com.

[Digil (Google Cloud Platform Support)]

From your error message, it doesn't look like an issue connected with a specific 'zone' or 'region'(in which your GCE instance resides). I further checked for any recent issues connected with the Google Compute Engine through the GCP's status board. But in the last seven days, there hasn't been any known issue reported with Google Compute Engine. 

As you probably know, SSH issues are quite common.  There could be many reasons behind the failure of an SSH connection. A corrupt SSH key, local firewall issues etc.. are some of them.

That's being said, a general troubleshooting SSH guide is provided here which I would strongly recommend you to refer for very common scenarios that might cause an issue with SSH connection.

Below mentioned are few questions that you should also consider checking for a common SSH issues.

=====================

1) Do you have any internal rules on the ssh-server to filter source IPs that are allowed to connect?

(This could block all incoming connection on the port if the connection is from a restricted IP)

2) Have you tried with other user accounts? 

(This could indicate that the user is the issue and not the ssh-server configurations)

3) Are you using privately managed SSH keys?

(This could indicate that the keys are not properly formatted)

4) Have you  tried the  failed connection attempt using a verbosity debug flag?

(This will provide you with crucial clues as to why the connection is failing)

eg: gcloud compute ssh example-instance --zone <zone-name> --ssh-flag="-vvv"

I formulated all the above mentioned questions from the troubleshooting ssh guide.

5) Were you having the same SSH connection issue on any other instance in the same project? (This would confirm whether the issue is specific to a particular VM or not)

=====================

If the 'Troubleshooting SSH guide' didn't help you to access the VM, then the only option left would be to retrieve the data from your OLD VM through a newly created working VM. To achieve that you could  refer the answer provided in the stackoverflow.com thread.

I hope this helps.

[MIRSK Development]

hi

I am trying to connect from Denmark by using the Chrome browser

[MIRSK Development]

hi

I have found the issue.

The predefined firewall rule 'default-allow-ssh' is set to allow my external IP address only. If i change it to allow 0.0.0.0/0, then both SSH terminal and cloud shell works.

I don't want to completely open op for SSH to everyone. Can you tell me what IP sources i should allow in the default-allow-ssh rule to be able to use the SSH terminal?  

[MIRSK Development]

hi

I don't think this is a common SSH problem because we have many Google VM instances already that i can connect to using SSH (putty).

This is not a firewall issue of connecting via SSH to a VM.

my problem is that when I have created a new VM instance, I need to create the password for root user (used to login from putty). and change some other stuff on the VM to be able to make an SSH connection with putty from my own PC.

I usually do these changes through gcloud command in the Chrome browser. 

gcloud offers me the first command line to connect to the VM instance:

gcloud beta compute ssh --zone "us-central1-a" "myinstancename" --project "myproject"

when running this command, i am presented with a message box saying:

Authorize Cloud Shell

gcloud is requesting your credentials to make a GCP API call.

Click to authorize this and future calls that require your credentials. 

i click authorize and i execute the command with the suggested verbose flags:

Welcome to Cloud Shell! Type "help" to get started.

Your Cloud Platform project in this session is set to myproject.

Use “gcloud config set project [PROJECT_ID]” to change to a different project.

username@cloudshell:~ (myproject)$ gcloud beta compute ssh --zone "us-central1-a" "myinstancename" --project "myproject" --ssh-flag="-vvv"

OpenSSH_7.9p1 Debian-10+deb10u2, OpenSSL 1.1.1j  16 Feb 2021

debug1: Reading configuration data /etc/ssh/ssh_config

debug1: /etc/ssh/ssh_config line 19: Applying options for *

debug2: resolve_canonicalize: hostname XX.XX.XX.XX is address

debug2: ssh_connect_direct

debug1: Connecting to XX.XX.XX.XX [XX.XX.XX.XX] port 22.

debug1: connect to address XX.XX.XX.XX port 22: Connection timed out

ssh: connect to host XX.XX.XX.XX port 22: Connection timed out

ERROR: (gcloud.beta.compute.ssh) [/usr/bin/ssh] exited with return code [255].

username@cloudshell:~ ( myproject)$

If i can't make this work from the browser then i need another way to make an SSH connection to the newly created VM instance.

How do i do this when i don't have a username/password or a public/private key scenario setup on the instance?

On Thursday, March 4, 2021 at 4:59:33 PM UTC+1 MIRSK Development wrote:

[Pedro Moreno]

SSH via gcloud: Return Code 255

Troubleshooting Steps:

TIP: Return Code 255 is perfectly normal if the SSH session was terminated (for example, if you issued sudo reboot now). Code 255 usually results when SSH intentionally terminates a session and prevent user access due to errors (wrong permission on ./ssh/authorized_keys, authentication, etc), or simply the service is not reachable.

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

   • The instance has not finished starting up, or that the SSH session was terminated.
   • 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.

2. Make sure that the user has authenticated to gcloud as an IAM user with the compute instance admin role; for example, run gcloud auth revoke --all, gcloud auth login [IAM-USER] then try gcloud compute ssh again.

3. Logon using UI ssh. This creates an ephemeral ssh key, Google Agent also executes the codepath to refresh .ssh/authorized_keys and address any invalid dir/file permissions for both .ssh/ and .ssh/authorized_keys. This approach will address common gcloud compute ssh issues that relates to corrupted keys, missing dir/file or invalid dir/file permission. Try the gcloud again after performing the UI ssh.

4. Force gcloud to recreate the user's SSH key pair then try gcloud compute ssh again. Move the existing key pair aside using these commands:

   mv ~/.ssh/google_compute_engine ~/.ssh/old-google_compute_engine mv ~/.ssh/google_compute_engine.pub ~/.ssh/old-google_compute_engine.pub

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

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

7. Make sure that the instance has not run out of memory. 

8. Make sure the VM has started up successfully. Look for status in the serial console logs. If there are boot issues, they can be fixed by steps here.

9. Verify that persistent SSH Keys metadata for gcloud is set for either the project or instance. 

10. Authentication issues are logged in to /var/log/auth*.log, review this log for any errors. If this file can't be access due to inability to logon to the VM, this require detaching and attaching the boot disk to another VM in order to review the logs.
    

Official documentation about this Connection failed, code 255.