El inicio de sesión sin contraseña ssh falla con el permiso denegado (clave pública)

I am trying to set up passwordless ssh on two fresh linux VM's from VM A to VM B but I'm having permissions issues. I installed openssh-server on both vm's and configured /etc/ssh/sshd_config as follows: 

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile     %h/.ssh/authorized_keys
PasswordAuthentication no

All other fields are their default values. On VM A I ran ssh-keygen -t rsa with the default options. I tried to use ssh-copy-id but I got a permission denied(publickey) error. I then manually copied id_rsa.pub into authorized_keys on VM B. I used chmod 700 for ~/.ssh, chmod 600 for ~/.ssh/id_rsa, and chmod 644 for ~/.ssh/id_rsa.pub, ~/.ssh/authorized_keys, and ~/.ssh/known_hosts on both VM's. After running ssh -v VM-B I get the following output:

OpenSSH_5.9p1 Debian-5ubuntu1.1, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to hadoop-slave-1 [192.168.86.134] port 22.
debug1: Connection established.
debug1: identity file /home/hduser/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/hduser/.ssh/id_rsa-cert type -1
debug1: identity file /home/hduser/.ssh/id_dsa type -1
debug1: identity file /home/hduser/.ssh/id_dsa-cert type -1
debug1: identity file /home/hduser/.ssh/id_ecdsa type -1
debug1: identity file /home/hduser/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1.1
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 45:48:fd:f0:db:1a:2a:c0:80:17:ec:18:5a:dd:f2:a5
debug1: Host 'hadoop-slave-1' is known and matches the ECDSA host key.
debug1: Found key in /home/hduser/.ssh/known_hosts:1
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/hduser/.ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: Trying private key: /home/hduser/.ssh/id_dsa
debug1: Trying private key: /home/hduser/.ssh/id_ecdsa
debug1: No more authentication methods to try.
Permission denied (publickey).

¿Hay algo más que deba hacer?

preguntado el 27 de noviembre de 13 a las 05:11

When debugging sshd access issues, I often find that it helps to run sshd on the remote machine in non-daemon mode, e.g. sshd -D -d -p 8022. entonces ssh -p 8022 remotehost from the other machine. sshd tends to produce more informative error output than ssh does. -

5 Respuestas

Another cause of permission issues is the permissions set on the home directory. Check if this is 755 or less.

Ver http://www.openssh.org/faq.html#3.14 para más información.

respondido 27 nov., 13:06

tratar de seguir Inicios de sesión sin contraseña con OpenSSH

in particular this should work:

ssh-copy-id -i ~/.ssh/id_rsa.pub username@mystery

This will prompt you for the login password for the host, then copy the keyfile for you, creating the correct directory and fixing the permissions as necessary

respondido 27 nov., 13:06

I had tried this before and had a permissiondenied(publickey) error but this worked when I re-enabled password authentication temporarily. I also had to use ssh-add antes de usar ssh-copy-id which I had neglected to do before. - user2623855

FYI, I created a small script at github.com/centic9/generar-y-enviar-clave-ssh which runs the necessary steps in one go and additionally ensures all the file/directory permissions which always caused me headaches... - céntrico

I am facing same issue could you please help in this. - SANDEEP

This line in the log you posted doesn't look right:

debug1: Offering RSA public key: /home/hduser/.ssh/id_rsa

¿Podrías intentarlo?

ssh-copy-id remotemachine_username@remotemachine

respondido 27 nov., 13:06

Just so you know: on IBM AIX this doesn't work because there is no ssh-copy-id. chmod -R 755 ~/.ssh aunque funciona bien. - RAKK

try to change the PasswordAuthentication no to yes

Respondido 10 Abr '19, 09:04

This could easily by a comment. - baduker

After completing these steps, hduser will be able to login using ssh keys without having to use password authentication on VM B. (note: we'll enable password authentication while working, but disable it again once everything is in order)

  1. As root, open a terminal on VM B

  2. Configure sshd_config to temporarily allow password authentication and ensure that your root user can log back in if connection is lost during any part of this process.

    sudo nano /etc/ssh/sshd_config

    • Set PermitRootLogin to "yes" (we won’t be leaving it this way)

    • Set PasswordAuthentication to "yes" (this is also temporary)

    • Save changes and return to terminal

    ctrl + o luego Return/Enter

    ctrl + x

  3. Restart sshd services

    sudo systemctl restart sshd

  4. Become hduser

    su - hduser

  5. Remove /home/hduser/.ssh and replace it with a new (empty) ~/.ssh folder. Doing this as hduser ensures that hduser can write keys to this folder without having to specify ownership/group permissions with chmod (a common failure point in this process).

    rm -r ~/.ssh

    mkdir ~/.ssh

  6. Let's call the current terminal "VM B Terminal." Keep VM B Terminal open and spawn a new terminal on VM A; we'll call this "VM A Terminal."

  7. In VM A Terminal, we'll check for an "id_rsa.pub" file

    ls ~/.ssh

  8. If you see an "id_rsa.pub" file in here and know it to be a good key, you can safely move to the next step. Otherwise, generate a new key.

    ssh-keygen

    • Use the default options by pressing Enter/Return and typing "yes" when asked about saving the new key. You should now have a file called “id_rsa.pub” in your ~/.ssh folder.

  9. Use ssh-copy-id to copy hduser's credentials to the server. If ssh-copy-id is unavailable, scp is a good alternative.

    Opción 1 ssh-copy-id hduser@<ip-address>

    Opción 2 scp -r ~/.ssh hduser@<ip-address>:/home/hduser/.ssh

    • If successful, move on to the next step; otherwise, share your terminal output for further troubleshooting.

  10. Switching back to VM B Terminal

    sudo nano /etc/ssh/sshd_config

    PasswordAuthentication no

    • Save changes and return to terminal

  11. Restart sshd services

    sudo systemctl restart sshd

  12. From VM A Terminal, connect over ssh as hduser. Note: if hduser’s ssh-key is password protected (this is recommended), enter the file password when prompted.

    • Congratulations on your success! You may now secure your server.

  13. Configure sshd_config with production settings

    sudo nano /etc/ssh/sshd_config

    PermitRootLogin no

    • Guardar y Salir

    systemctl restart sshd

  14. Test hduser's connection again before closing out VM B terminal.

respondido 14 mar '20, 02:03

No es la respuesta que estás buscando? Examinar otras preguntas etiquetadas or haz tu propia pregunta.