SSH demande toujours le mot de passe après avoir configuré l'authentification basée sur les clés

J'ai réussi à créer une authentification basée sur une clé pour l'utilisateur root de ma machine A à ma machine B.

Maintenant, j'ai créé un nouvel utilisateur sur la machine B, le même que sur la machine A, appelons-le USER. J'ai créé un répertoire personnel pour lui sur la machine B /home/USERet je veux créer une authentification basée sur des clés pour lui de la machine A à la machine B.

Alors j'ai couru sur une machine

1. ssh-keygen -t rsa, a accepté tous les chemins, donc /home/USER/.ssh/id_rsaet sans phrases
2. ssh-copy-id -i /home/USER/.ssh/id_rsa.pub USER@BmachinesIP, entré un mot de passe et obtenu un massage

Maintenant, essayez de vous connecter à la machine bla bla bla

Donc, tout semble aller bien.

Mais quand j'ai essayé de ssh USER@BmachinesIPme connecter, on m'a demandé un mot de passe. J'ai essayé de voir le journal et j'ai couru ssh -vvv USER@BmachinesIPet voici une partie de la sortie:

debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /home/USER/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/USER/.ssh/id_dsa
debug3: no such identity: /home/USER/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
USER@BmachinesIP's password:

Alors, quelqu'un peut-il me dire ce que j'ai fait de mal ou ce que je dois changer? Peut-être que le problème réside dans les autorisations, les voici:

sur une machine:

drwx------  2 USER USER    SIZE DATE TIME .ssh
-rw-------  1 USER USER 1675 2011-10-31 14:36 id_rsa
-rw-r--r--  1 USER USER 413 2011-10-31 14:36 id_rsa.pub

et sur la machine B:

drwx------  2 USER defaultGroup    SIZE DATE TIME .ssh
-rw-------    1 USER defaultGroup    SIZE DATE TIME authorized_keys

J'ai trouvé une solution. Un problème est survenu dans les autorisations.

/home/USER sur la machine distante a reçu toutes les autorisations, mais pour l'authentification basée sur les clés, elle doit être définie sur 755

Même problème pour moi, une nouvelle installation de CentOS7.

1. Vérifiez les autorisations du répertoire d' accueil et les autorisations ~ / .ssh et ~ / .ssh / authorized_keys (selon @erik)

chmod o-w ~/; chmod 700 ~/.ssh; chmod 600 ~/.ssh/authorized_keys

2. Vérifiez les paramètres / etc / ssh / sshd_config && service sshd restart (après chaque modification) Utile: essayez "LogLevel VERBOSE" dans sshd_config.

J'ai toujours reçu une invite de mot de passe après avoir vérifié tout ce qui était ok.

Exécutez le client ssh avec les journaux -vvv:

debug3: send_pubkey_test 
debug2: we sent a publickey packet, wait for reply

Journaux du serveur (/ var / log / secure):

Failed publickey for * from * port * ssh2: RSA *

Le serveur ssh n'envoie pas plus d'informations d'erreur au client car cela constituerait un risque pour la sécurité.

Si j'ai exécuté sshd sur un port différent, «sshd -p 5555 -d». La clé a fonctionné. Connexion sans mot de passe ok. WTF?

Ensuite, j'ai désactivé selinux (définir SELINUX = désactivé dans / etc / selinux / config) et redémarrer. La connexion sans mot de passe a alors fonctionné correctement.

mes paramètres sshd_config actuels:

[root@hp-bl-05 ~]# grep -vE "^#|^$" /etc/ssh/sshd_config  
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
SyslogFacility AUTHPRIV
LogLevel VERBOSE
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys
HostbasedAuthentication yes
PasswordAuthentication yes
ChallengeResponseAuthentication no
GSSAPIAuthentication no
GSSAPICleanupCredentials no
UsePAM yes
X11Forwarding yes
UseDNS no
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE
AcceptEnv XMODIFIERS
Subsystem   sftp    /usr/libexec/openssh/sftp-server

Il serait donc intéressant de savoir si nous pouvons modifier quelque chose de petit dans selinux pour que la connexion ssh sans mot de passe fonctionne. Quelqu'un peut-il améliorer la réponse?

La solution n'est pas de désactiver SELinux mais de corriger les autorisations SELinux du répertoire utilisateur. Le contexte du répertoire utilisateur doit être défini sur user_home_t.

Vérifier,

$ sudo ls -Z /home/

Si le contexte de votre répertoire utilisateur est différent de user_home_t, SELinux n'autoriserait pas SSH via une clé publique dans ce répertoire utilisateur pour cet utilisateur.

Pour réparer,

$ sudo semanage fcontext -a -t user_home_t /home/azureuser
$ sudo restorecon -vvRF /home/azureuser

La connexion basée sur les clés devrait maintenant fonctionner.