gcloud compute ssh returns Permission Denied (publickey)

Question

According to Google Cloud documentation, if I am a project member with the "compute instance admin" role, I should be able to connect to any instance in my project using the gcloud tool.

On the project IAM page in the Google Cloud console, I have explicitly added my username with the "Compute Instance Admin (v1)" role, yet I am still unable to connect to an instance created by some of our automation.

[username]:~/src/infrastructure$ gcloud compute ssh [instance id]
Unauthorized use is strictly prohibited. All access and activity
is subject to logging and monitoring.
Permission denied (publickey).
ERROR: (gcloud.compute.ssh) [/usr/bin/ssh] exited with return code [255].

The only instances I seem to be able to connect to are those created by me.

What might be going wrong here?

As a side note, according to this documentation, I should be able to add my RSA public key to the instance manually, then connect using SSH.

I added my public key from ~/.ssh/google_compute_engine.pub to the instance metadata, then tried using SSH, with no luck.

[username]:~/src/infrastructure$ ssh -i ~/.ssh/google_compute_engine [public ip of instance]
Unauthorized use is strictly prohibited. All access and activity is subject to logging and monitoring.
Received disconnect from 35.197.127.143 port 22:2: Too many authentication failures for matts
Connection to 35.197.127.143 closed by remote host.
Connection to 35.197.127.143 closed.

As Google recommends, I do not want to manually manage SSH keys for instance access. I want gcloud compute ssh to work, so I'm less focused on this second failure than I am on the first one (unless they're related).

Answer 1

In our case the reported problem was misleading

$ gcloud compute ssh "[user]@[instance]"
Permission denied (publickey).

With verbose printing the actual problem became a bit more clear:

$ gcloud compute ssh "[user]@[instance]" -v
...
send_pubkey_test: no mutual signature algorithm
...
Permission denied (publickey).

And the way we could resolve this was by accepting RSA as a valid algorithm (note that this was an old debian OS we needed to connect to):

$ gcloud compute ssh "[user]@[instance]" --ssh-flag="-o PubkeyAcceptedKeyTypes=+ssh-rsa"

Answer 2

I was trying to connect to ssh into a VM on gcloud from a docker container. The default user when running a Docker container is named root.

Unless specified, the gcloud compute ssh command uses the local username just as ssh would. Now, the key propagation does not seem to like the name root. The only indication was from the serial-port-output of the machine:

[    5.621630] google_metadata_script_runner[638]: 2020/10/21 09:43:01 logging client: rpc error: code = PermissionDenied desc = The caller does not have permission
[    5.622286] google_guest_agent[635]: 2020/10/21 09:43:01 logging client: rpc error: code = PermissionDenied desc = The caller does not have permission
Oct 21 09:43:01 private-cluster-bastion-dced90d6 google_metadata_script_runner[638]: 2020/10/21 09:43:01 logging client: rpc error: code = PermissionDenied desc = The caller does not have permission
Oct 21 09:43:01 private-cluster-bastion-dced90d6 google_guest_agent[635]: 2020/10/21 09:43:01 logging client: rpc error: code = PermissionDenied desc = The caller does not have permission

I was able to get this to work by adding a USER@ prefix to the machine name as mentioned in https://cloud.google.com/sdk/gcloud/reference/compute/ssh#USER

Pretty much any user name works.

Answer 3

This happened to me after updating to Ubuntu 22.04. So from what I found out from here:

The RSA SHA-1 hash algorithm is being quickly deprecated across operating systems and SSH clients because of various security vulnerabilities, with many of these technologies now outright denying the use of this algorithm.

It seems this has happened for the ssh client in Ubuntu 22.04. The RSA public-private key pair is considered not safe any more.

So to fix this, as mentioned in the above link, I created a different key using ed25519 with the following command

ssh-keygen -t ed25519 -C "myname"

This will generate a new key in path ~/.ssh/id_ed25519 . If you want you specify a different path using -i parameter in the above command.

Once the new key is generated, use the same key in the ssh command using the ssh-key-file param:

gcloud compute ssh  "my-instance" --ssh-key-file=~/.ssh/id_ed25519

P.S. I was able to ssh into some of the instances even after upgrading to 22.04, but was not working for some. After the above steps, it working for all now.

Answer 4

This problem may happen if you delete the .ssh/authorized_keys file, and you may be able to fix the connection for the user with the problem if you have access to the machine through another user, usually that can be done with the following command ran by that other user:

gcloud compute ssh <machine-name> --project <project> --zone <zone>

Create the user's .ssh/authorized_keys file by adding the .ssh/google_compute_engine.pub key from the machine you are trying to connect from.

sudo -i

cd /home/<misconfigured-user>

# Optional, verify the keys are not already set.
cat .ssh/authorized_keys

touch .ssh/authorized_keys

Edit the file with your favorite editor and paste the local machine value.

Then just set the proper permissions for the file, it may not be necessary, but these are the default permissions.

chown <user> ~/.ssh/authorized_keys
chgrp <user> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Answer 5

If you have OS Login enabled on your virtual machine, you cannot connect via SSH. Disable OS Login with the command:

gcloud compute project-info add-metadata \
--metadata enable-oslogin=FALSE

This solved my issue.

Answer 6

I had this problem. I couldn't login with gcloud command, manual ssh with -i flag, or even using the web browser ssh client.

I also tried to manually add a new key in the ssh keys editor which seemed to go through fine but STILL didn't let me in.

Increasing the boot disk size and restarting the instance fixed the problem.

Answer 7

Refer to this process documentation to update the SSH keys. Also, it is possible that your instance have outdated VM guest environment. In addition, check out this issue report, some suggestions may work for you. Error 255 is very generic error.