ERROR: (gcloud.compute.ssh) [/usr/bin/ssh] exited

问题:

I kept getting kicked out of my compute engine instance after a few seconds of idle with the indicated error (255). I used 'gcloud compute ssh' to log in. I am using the default firewall setting, which I believe would be good enough for ssh. But if I am missing something, please so indicate and suggest the fix for this error. Basically I can't get any efficient work done at this point having to ssh in so many times.

Thanks in advance.

Anh-

回答1:

gcloud denies an ssh connection if there was a change in the setup, e.g. after you changed your default zone or region, or you created another instance. Then, you must update the ssh keys in your metadata by

sudo gcloud compute config-ssh

If this complains about different entries in your config file where your ssh key entries are stored, ~/.ssh/config, delete this file and execute the above command again.

回答2:

255 is the interactive ssh exit code for ssh failure - otherwise interactive ssh exits with the exit code of the last command executed in the ssh session.

The next time you get exit code 255 from ssh try running with --ssh-flag="-vvv" (more v's => more debugging output) and see if it helps track down connection problems.

回答3:

For those who stop by this page. This helped me to solve the problem. Try to the following:

• Go to your Google and remove the SSH key for the server
• Run the gcloud command again

It seems a feature/issue from Google Cloud Platform itself, we are going to continue checking it.

回答4:

IT was my mistake stating that the default firewall would allow all connections into an instance. The contrary turned out to be true. Please refer to an appropriate firewall rule must be set up to allow connection into an instance

Anh-

回答5:

If the default network was edited, or if not using the default network, you may need to explicitly enable ssh access by adding a firewall-rule:

$ gcloud compute firewall-rules create --network=YOUR_NETWORK \
default-allow-ssh --allow tcp:22

After that, retry the 'gcloud compute ssh' command.

回答6:

This is a real problem with very little documentation to dealing with it.

Sometime after creating the instance using the gcloud sdk ssh snippet provided via GCP console stopped working and continually errors with 255 making connecting to ssh on the instance only available through browser via GCP console for the compute instance in question. Not to mention this has happened to me on many different instances some without touching the default account permissions after initial setup and deployment which is overly frustrating. Cause for no reason it just stops working...works, then doesn't...

The only thing that worked for me was creating a new user to connect with through gcloud sdk! Be it Windows/PowerShell or Linux locally, using the following snippet:

gcloud compute ssh newuser-name@instance-name

That all per GCP documentation here: https://cloud.google.com/compute/docs/troubleshooting/troubleshooting-ssh

Everything else passed per suggestions in documentation - port 22 open with access meaning it has to be a a problem with the default users authorization_keys WHICH they provide absolutely no documentation on how to fix that - at least nothing I could find on fixing (not creating or deleting)

I've tried updating the account, tried deleting the user and credentials from the instance, nothing appears to work. using:

gcloud compute --project "project-name" ssh --zone "us-east4-a" "instance-name"

Just doesn't work... - even tried 'gcloud compute config-ssh --force-key-file-overwrite' NOTHING WORKS...

But creating a new user works every time, and once the user is created you can keep using that user via gcloud sdk

It's a work around, and I hate work around's for things like this but for my sanity this works at least until I can figure out how to reset the default account permissions, so if anyone has any ideas there or can point me in a direction for that I'd more than appreciate it!

回答7:

Maybe this will help someone. I ran into this issue when I was behind my work's firewall. Once I connected to a public wifi, everything worked perfectly.