0

I've been trying to solve this for a few days without luck and similar questions/answers on this site don't solve the problem.

I have 3 different VM Instances on GCE and everything works fine on two of them.

With the third I have lost all access to SSH in through both the terminal built into console and also directly via Terminal on Mac.

I have created new key pairs and added the public key to the meta and ssh key section after clicking edit on the VM instance.

I keep getting the "Permission denied (publickey)" error. Port 22 is fine, IP is whitelisted, and I've generated multiple replacement SSH key pairs to try and fix this. Nothing works. I cannot SSH in and my SFTP client doesn't connect with the new keys (even though I have absolutely no problem with other instances to ssh or sftp).

There are multiple ssh keys in the .ssh folder but I don't think that's the issue because the other keys continue to work with different VM instances. It seems like something on the server that is watching for the keys is corrupt or the cache is stuck and it needs flushing. If this is the case any help knowing which file and what to do would really help. Also how do I even edit these files if I cannot get in there with ssh?

Below is the result of -v:

Bobcomp:.ssh Bob$ sudo ssh -v [SERVER USER]@[SERVER IP]
OpenSSH_7.9p1, LibreSSL 2.7.3
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 48: Applying options for *
debug1: Connecting to [SERVER IP] [[SERVER IP]] port 22.
debug1: Connection established.
debug1: identity file /var/root/.ssh/id_rsa type -1
debug1: identity file /var/root/.ssh/id_rsa-cert type -1
debug1: identity file /var/root/.ssh/id_dsa type -1
debug1: identity file /var/root/.ssh/id_dsa-cert type -1
debug1: identity file /var/root/.ssh/id_ecdsa type -1
debug1: identity file /var/root/.ssh/id_ecdsa-cert type -1
debug1: identity file /var/root/.ssh/id_ed25519 type -1
debug1: identity file /var/root/.ssh/id_ed25519-cert type -1
debug1: identity file /var/root/.ssh/id_xmss type -1
debug1: identity file /var/root/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.9
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4p1 Debian-10+deb9u6
debug1: match: OpenSSH_7.4p1 Debian-10+deb9u6 pat OpenSSH_7.0*,OpenSSH_7.1*,OpenSSH_7.2*,OpenSSH_7.3*,OpenSSH_7.4*,OpenSSH_7.5*,OpenSSH_7.6*,OpenSSH_7.7* compat 0x04000002
debug1: Authenticating to [SERVER IP]:22 as '[SERVER USER]'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
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:LOMx9T+sBw/LBUQvhsbaou5H4AwAMbUcnSWYzP0yKv0
debug1: Host '[SERVER IP]' is known and matches the ECDSA host key.
debug1: Found key in /var/root/.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: Will attempt key: /var/root/.ssh/id_rsa 
debug1: Will attempt key: /var/root/.ssh/id_dsa 
debug1: Will attempt key: /var/root/.ssh/id_ecdsa 
debug1: Will attempt key: /var/root/.ssh/id_ed25519 
debug1: Will attempt key: /var/root/.ssh/id_xmss 
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /var/root/.ssh/id_rsa
debug1: Trying private key: /var/root/.ssh/id_dsa
debug1: Trying private key: /var/root/.ssh/id_ecdsa
debug1: Trying private key: /var/root/.ssh/id_ed25519
debug1: Trying private key: /var/root/.ssh/id_xmss
debug1: No more authentication methods to try.
[SERVER USER]@[SERVER IP]: Permission denied (publickey).

Any help appreciated.

Matt
  • 1

1 Answers1

0

You need to specify the path of the private key when you run the SSH command:

ssh -i [PATH_TO_PRIVATE_KEY] [USERNAME]@[EXTERNAL_IP_ADDRESS]

Here is how to locate the key [1].

For more information on how to troubleshoot this kind of issues [2].

__

[1] https://cloud.google.com/compute/docs/instances/adding-removing-ssh-keys#locatesshkeys

[2] https://cloud.google.com/compute/docs/instances/connecting-advanced

  • Hi Alan, Thanks for the reply. I do reference the the path to private key as you stated when I usually connect but still get the "permission denied (public key)" error. I'm on with second level tech at Google trying to solve this. It seems as though the user I'm using is somehow corrupt or the wrong settings for the user are cached somewhere. – Matt Aug 05 '19 at 14:54
  • If the problem is the user , you can enable OS Login in order to access to the instance [1] ___ [1] https://cloud.google.com/compute/docs/instances/managing-instance-access – Alan Rodriguez Aug 06 '19 at 06:58