1

I'm not sure if this is a problem related to the Debian version because I don't have this problem in an old debianv8.

I'm trying to add a new ssh key to my instance (I have one user it is working) in a Debian9 and I did it following the GCP documentation https://cloud.google.com/compute/docs/instances/adding-removing-ssh-keys#block-project-keys and I tried with the SSH key metadata and/or SSH key in the instance, and the error is the same, I cannot log-in in the instance "Permission denied (publickey)".

What I can see is, the GCP console is not adding the pubkey on the ~/.ssh/authorized_keys file and I tried adding this manually but still not working and what I saw from con my configuration file the ssh daemon is not reading the data from here, but I don't know where is getting the ssh keys.

This is my ssh configuration file

#   $OpenBSD: sshd_config,v 1.100 2016/08/15 12:32:04 naddy Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.

#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key

# Ciphers and keying
#RekeyLimit default none

# Logging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
PermitRootLogin no
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#PubkeyAuthentication yes

# Expect .ssh/authorized_keys2 to be disregarded by default in future.
#AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2

#AuthorizedPrincipalsFile none

Does anyone else have this same problem, I tried as well to login from the SSH Web Version with my GCP account but I have a similar error.

Transferring metadata to VM is failing

  • 1
    Usually, this error means that the file permissions for the public key are wrong and/or the parent directory. Turn on debug for the SSH client that you are using and read the debug output. – John Hanley Aug 03 '19 at 22:24
  • the public key is the same on two machines, and I can log in in a debian8, the problem is debian9. I will try to turn on debug to see if I can see somthing, thanks – Michel Zúñiga Aug 04 '19 at 12:42
  • 1
    I did not mention that the keys are different I said the "File Permissions". The file must be readonly. – John Hanley Aug 04 '19 at 17:25
  • @MichelZúñiga just as a kind reminder take a look here https://serverfault.com/help/someone-answers – Jose Luis Delgadillo Apr 12 '21 at 18:27

2 Answers2

1

There are a couple of things to check why the SSH is failing, for example:

If the instance has OS Login enable then connecting with metadata-based SSH keys is not allowed.

If you are using a third party tool to access by SSH please ensure that you are using the private key correctly and the public is added to the instance metadata.

To troubleshoot this please refer to this documentation [1].

To verify your keys and connecting using advance methods, please follow this documentation [2].


[1] https://cloud.google.com/compute/docs/troubleshooting/troubleshooting-ssh

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

0

As it was mentioned by @John Hanley at the comment section, such the issue could be related to permissions and ownership. For example, if you want to login as username,.ssh and authorized_keys must belong to username. Otherwise, sshd won't be able to read them and therefore won't be able to tell if the user is authorized to login.

To fix permissions go to your home directory and run command below:

    cd ~
    chown -R username:username .ssh

after that you should set rights:

    chmod 700 .ssh
    chmod 600 .ssh/authorized_keys

You can check the result with command ls -la

Serhii Rohoza
  • 1,424
  • 2
  • 5
  • 15