web-dev-qa-db-fra.com

Impossible de faire fonctionner l'authentification par clé publique SSH

Mon serveur exécute CentOS 5.3. Je suis sur un Mac exécutant Leopard. Je ne sais pas qui est responsable de cela:

Je peux très bien me connecter à mon serveur via l'authentification par mot de passe. J'ai suivi toutes les étapes de configuration de PKA (comme décrit sur http://www.centos.org/docs/5/html/Deployment_Guide-en-US/s1-ssh-beyondshell.html ), mais lorsque j'utilise SSH, il refuse même de tenter une vérification publickey. Utilisation de la commande

ssh -vvv user@Host

(où -vvv augmente la verbosité au niveau maximum) J'obtiens la sortie pertinente suivante:

debug2: key: /Users/me/.ssh/id_dsa (0x123456)
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-with-mic,password
debug3: preferred keyboard-interactive,password
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password

suivi d'une invite pour mon mot de passe. Si j'essaie de forcer le problème avec

ssh -vvv -o PreferredAuthentications=publickey user@Host

Je reçois

debug2: key: /Users/me/.ssh/id_dsa (0x123456)
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-with-mic,password
debug3: preferred publickey
debug3: authmethod_lookup publickey
debug3: No more authentication methods to try.

Donc, même si le serveur dit qu'il accepte la méthode d'authentification publickey et que mon client SSH y insiste, je suis réfuté. (Notez l'absence évidente d'une ligne "Offrant la clé publique:" ci-dessus.) Des suggestions?

ssh
41
Trey Parkman

Vérifiez que votre machine Centos a:

RSAAuthentication yes
PubkeyAuthentication yes

dans sshd_config

et assurez-vous que vous disposez des autorisations appropriées sur le répertoire ~/.ssh/de la machine centos.

chmod 700 ~/.ssh/
chmod 600 ~/.ssh/*

devrait faire l'affaire.

44
pyhimys

J'ai eu un problème similaire - un PC distant ne pouvait pas utiliser l'authentification par clé publique pour se connecter au serveur CentOs 6. Le problème dans mon cas était lié à SELinux - le répertoire personnel de l'utilisateur essayant de se connecter avait des contextes de sécurité de message. J'ai résolu cela en utilisant l'outil restorecon ainsi:

restorecon -Rv /home
17
Gareth

1- Vérifiez votre/etc/ssh/sshd_config, assurez-vous que vous avez

 RSAAuthentication oui 
 PubkeyAuthentication oui

2- Vérifiez le journal sécurisé de la machine distante, recherchez le journal détaillé des erreurs du démon sshd. par exemple. dans mon Ubuntu

 # grep 'sshd'/var/log/secure | grep 'Authentification refusée' | tail -5 
 4 août 06:20:22 xxx sshd [16860]: Authentification refusée: propriété ou modes incorrects pour le répertoire /home/xxx[.______________ 4 août 06:20:22 xxx sshd [16860 ]: Authentification refusée: propriété ou modes incorrects pour le répertoire /home/xxx[.____.. 4 août 06:21:21 xxx sshd [17028]: Authentification refusée: propriété ou modes incorrects pour le répertoire /home/xxx
 4 août 06:21:21 xxx sshd [17028]: Authentification refusée: propriété incorrecte ou modes pour le répertoire /home/xxx[.______________ 4 août 06:27:39 xxx sshd [20362]: Authentification refusée: propriété incorrecte ou modes pour le répertoire /home/xxx

Ensuite, vérifiez la propriété et les modes du répertoire/home/xxx, vous devrez peut-être l'exécuter

 chmod 755 /home/xxx
13
Jinyu Liu

Vérifiez que vos autorisations sont correctes et que la structure des fichiers (en particulier l'orthographe) est correcte, pour les machines locales et distantes. L'URL à laquelle vous vous référez les énonce tous, mais cela vaut la peine de vérifier que ce que vous avez correspond. Normalement, les autorisations génèrent une erreur pertinente.

Avez-vous vérifié que le sshd_config sur votre boîte CentOS 5.3 est défini pour autoriser PubkeyAuthentication ou RSAAuthentication?

Vérifiez les journaux du serveur SSH sur le système CentOS - cela peut fournir plus d'informations. Je ne sais pas si CentOS effectue la vérification de la clé ssh sur liste noire que fait Debian, mais j'ai vu des rejets de ssh publickey qui sont relativement silencieux en ce qui concerne la sortie -vvv, mais les journaux expliquaient assez clairement ce qui se passait

11
Daniel Lawson

Je l'ai! Il s'avère que c'était un problème côté client. (Je pense que n'importe quel problème côté serveur aurait produit une sortie de débogage plus utile.) Pour des raisons inconnues de moi, sur mon Mac, le fichier/etc/ssh_config avait la ligne

PubkeyAuthentication = no

J'ai commenté cette ligne, et maintenant tout fonctionne bien.

7
Trey Parkman

Outre les modes de fichiers/répertoires, assurez-vous que la propriété est correcte! Un utilisateur doit posséder son propre répertoire personnel, .ssh/et ses fichiers.

Je devais courir chown -R $user:$user /home/$user pour surmonter mes échecs ssh.

4
Visser

Cela me semble être un problème de configuration. Comme Daniel l'a suggéré, il y a deux choses à vérifier:

  1. Les clés SSH dans $HOME/.ssh/authorized_keys sont lisibles; et
  2. SSHd est configuré pour autoriser la connexion par clé publique.
2
sybreon

Vérifiez le nom d'utilisateur avec lequel vous essayez de vous connecter. Par défaut, c'est votre nom d'utilisateur sur la machine locale.

2
Creotiv

Vérifiez également qu'il peut fournir automatiquement une clé ou non, utilisez -i chemin/vers/clé sinon ou juste pour tester

2
Jimsmithkka

je viens d'être pris au piège dans le même problème d'accès avec Fedora core 16 à cents 5,5

les journaux et verbeux étaient exactement les mêmes

le problème était la clé publique, il a obtenu de fausses données, les régénérer et les publier dans le serveur sshd_client, vous sshd_client envoie les informations de clé mais n'est pas reconnu par le serveur (il ne correspond à aucune des clés de authorized_keys)

1
Freaktor

La sortie du client comme dans ssh -v révélera qu'il y a un problème à une certaine étape du protocole, mais quand il est dû à quelque chose sur le serveur, le client ne sera pas informé de la cause. Vérifiez les fichiers journaux du serveur pour savoir ce qui ne va pas. Vous devez probablement être root pour avoir les autorisations nécessaires. Par exemple, pour un sshd configuré pour se connecter à syslog, vous pouvez trouver les messages dans /var/log/secure. Comme ceux-ci:

Authentication refused: bad ownership or modes for directory /home/you/.ssh
Authentication refused: bad ownership or modes for file /home/you/.ssh/authorized_keys

La raison dans ce cas était un (stupide) défaut default de 0002. Cela signifie, accès en écriture pour le groupe. (Groupname = nom d'utilisateur, mais quand même.) Le démon SSH ne fera pas confiance aux fichiers qui peuvent être falsifiés par d'autres que l'utilisateur (enfin, et root, bien sûr). Vous pouvez résoudre le problème en utilisant chmod.

chmod 700 ~/.ssh # solve the issue
chmod 720 ~/.ssh # reproduce the issue
# or similar for a file
1
Lumi