Permission denied (publickey) when connecting to VM via terminal

[Simon Layfield]

Hey guys,

The first time I've encountered this issue but I've added my public SSH key to the VM, checked the Project Metadata (doesn't seem to be anything wrong there) and I'm still unable to connect via ssh to my VM.

I actually migrated this VM from a different instance, so could there be something I'm missing in the configuration that might be preventing me from connecting?

Any help would be much appreciated.

Thanks,

Simon

[Fady (Google Cloud Platform)]

Hello Simon,

There could be multiple reasons for the ssh issue you are reporting. I suggest following this guide for troubleshooting. Also, there is this public issue tracker that could be addressing the error message. However, I suspect you could be having one of the following :

1. Your root disk is full. You may check this thread to troubleshoot.

2. If you migrated an old GCP VM, your linux guest environment could be outdated. You may use the legacy sshKeys  (capital K) as a metadata key attached to the VM rather than ssh-keys per this issue, then reinstall the guest environment.

On the other hand, you could use the verbosity flag to get more information about the error, like this thread if using putty in Windows, this thread in cloud shell or using the SDK, or by using:

ssh -v server.example.com

I hope this helps.

[Simon Layfield]

Thanks Fady.

I'll take a look at the links you provided - thanks. In the meantime, below is the output in the terminal.

Seems like it's more of an issue with the SSH keys, or at least that's what it looks like to me.

Is that also a possibility?

Apologies. My technical understanding of these things only goes so far so I'm a little slow on the uptake.

Executing: program /usr/bin/ssh host XXXXX, user XXXXXX, command scp -v -t /var/www/html




OpenSSH_7.4p1, LibreSSL 2.5.0


debug1: Reading configuration data /etc/ssh/ssh_config


debug1: Connecting to XXXXXX [XXXXXXXX] port 22.


debug1: Connection established.


debug1: identity file /Users/XXXXXXX/.ssh/id_rsa type 1


debug1: key_load_public: No such file or directory


debug1: identity file /Users/XXXXXXX/.ssh/id_rsa-cert type -1


debug1: key_load_public: No such file or directory


debug1: identity file /Users/XXXXXXX/.ssh/id_dsa type -1


debug1: key_load_public: No such file or directory


debug1: identity file /Users/XXXXXX/.ssh/id_dsa-cert type -1


debug1: key_load_public: No such file or directory


debug1: identity file /Users/XXXXXXX/.ssh/id_ecdsa type -1


debug1: key_load_public: No such file or directory


debug1: identity file /Users/XXXXXX/.ssh/id_ecdsa-cert type -1


debug1: key_load_public: No such file or directory


debug1: identity file /Users/XXXXXX/.ssh/id_ed25519 type -1


debug1: key_load_public: No such file or directory


debug1: identity file /Users/XXXXXX/.ssh/id_ed25519-cert type -1


debug1: Enabling compatibility mode for protocol 2.0


debug1: Local version string SSH-2.0-OpenSSH_7.4


debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7p1 Debian-5+deb8u1


debug1: match: OpenSSH_6.7p1 Debian-5+deb8u1 pat OpenSSH* compat 0x04000000


debug1: Authenticating to XXXXXXX:22 as 'XXXXXXXXX'


debug1: SSH2_MSG_KEXINIT sent


debug1: SSH2_MSG_KEXINIT received


debug1: kex: algorithm: curve25519-sha256@libssh.org


debug1: kex: host key algorithm: ecdsa-sha2-nistp256


debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none


debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none


debug1: expecting SSH2_MSG_KEX_ECDH_REPLY


debug1: Server host key: ecdsa-sha2-nistp256 SHA256:XXXXXXX

debug1: Host 'XXXXXXX' is known and matches the ECDSA host key.


debug1: Found key in /Users/XXXXXXXXX/.ssh/known_hosts:1


debug1: rekey after 134217728 blocks


debug1: SSH2_MSG_NEWKEYS sent


debug1: expecting SSH2_MSG_NEWKEYS


debug1: SSH2_MSG_NEWKEYS received


debug1: rekey after 134217728 blocks


debug1: SSH2_MSG_SERVICE_ACCEPT received


debug1: Authentications that can continue: publickey


debug1: Next authentication method: publickey


debug1: Offering RSA public key: /Users/XXXXXXX/.ssh/id_rsa


debug1: Authentications that can continue: publickey


debug1: Trying private key: /Users/XXXXXXXX/.ssh/id_dsa


debug1: Trying private key: /Users/XXXXXXXXX/.ssh/id_ecdsa


debug1: Trying private key: /Users/XXXXXXXXX/.ssh/id_ed25519


debug1: No more authentication methods to try.


Permission denied (publickey).


lost connection

[Fady (Google Cloud Platform)]

I suggest to use this gcloud command in cloud shell, as the ssh command above needed the path to the public keys, and then privately send me the output :

gcloud compute ssh [instance name] --ssh-flag="-vvv"  --force-key-file-overwrite --verbosity debug

Also, I would like to know if you followed this guide when you migrated. If not, how did you migrate the instance?  But first , you may try to isolate the issue by removing the public key from the instance’s metadata, and then try to SSH through the browser (button), or cloud shell. It should create/use the project-wide key pair automatically for you. If it goes through, then your issue could be related to properly creating the instance-level key pairs.

If that fails then it could be one of the issues I mentioned in my past post, and you would have to follow the troubleshooting guides. You could also try through interacting with the serial port console to reinstall the guest environment. But, you may have to create a username and password (sudoer) by running a metadata startup script .

On Monday, November 6, 2017 at 6:15:06 PM UTC-5, Simon Layfield wrote:

[Simon Layfield]

Apologies Fady - it may well be that the issues is one of the aspects you've mentioned, but unfortunately my knowledge of these things is drastically limited. Until now I've been able to create VM instances, add ssh keys and connect via the terminal - no problem. Now, it seems, I'm receiving the same error message in the terminal when trying to connect to multiple VMs.

Unfortunately, my knowledge being so limited, I think I'll have to look towards another solution for hosting.

Thanks.

Simon

[Simon Layfield]

Ok - update.

I've successfully managed to transfer files using the gcloud command, so despite having not been able to work out what the issue was with connecting via ssh in the terminal this will be how I do this moving forward.

From memory, I migrated by creating an image of the instance and then creating a new instance from that image. I'm a little hazy on the details, but at any rate I'm pretty sure that didn't have anything to do with the issue as I was also having trouble with other instances that had not been migrated.

Thanks for you help. I appreciate you taking the time to respond!

Simon

[Fady (Google Cloud Platform)]

I am glad that you are able to ssh. If using the gcloud command works, then the issue when using the terminal could be with the key pair you have generated. As I mentioned in my past message, when using the Gcloud command or SSH from the browser, it should automatically create the keys for you. For transferring files, you may use this Gcloud command that implements the SCP protocol. I hope this helps.