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

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

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

ssh -vvv user@host

(où -vvv augmente le niveau de verbosité jusqu'au niveau maximal), j'obtiens le résultat pertinent suivant:

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 insiste dessus, je suis contrefait. (Notez l’absence évidente d’une ligne "Offrir une clé publique:" ci-dessus.) Des suggestions?

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.

J'ai eu un problème similaire: l'ordinateur distant n'a pas pu 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 de base de l'utilisateur essayant de se connecter contenait des messages contenant des contextes de sécurité. J'ai résolu ceci en utilisant l' restoreconoutil ainsi:

restorecon -Rv /home

1- Vérifiez votre / etc / ssh / sshd_config, assurez-vous d’avoir

Authentification RSAA oui
PubkeyAuthentication oui

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

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

Puis vérifiez la propriété et les modes pour directory / home / xxx, peut-être devez-vous exécuter ceci

chmod 755 / home / xxx

Vérifiez que vos autorisations sont correctes et que la structure du fichier (en particulier l'orthographe) est correcte, pour les ordinateurs locaux et distants. L'URL à laquelle vous vous référez les énonce tous, mais il est utile de vérifier que ce que vous avez correspond. Normalement, les autorisations génèrent une erreur pertinente.

Avez-vous vérifié que sshd_config de 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 - il peut fournir plus d'informations. Je ne sais pas si CentOS vérifie ce que fait Debian avec la clé ssh sur liste noire, mais j'ai déjà vu des rejets sick publickey qui sont relativement silencieux en ce qui concerne la sortie de -vvv, mais les journaux expliquent assez clairement ce qui se passait.

Je l'ai! Il s'avère que c'était un problème côté client. (Je pense que tout 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 comportait la ligne

PubkeyAuthentication = no

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

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

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

Vérifiez également qu'il peut fournir automatiquement une clé ou non, utilisez -i chemin / vers / clé si ce n'est pas le cas ou juste pour tester

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

1. Les clés SSH $HOME/.ssh/authorized_keyssont lisibles. et
2. SSHd est configuré pour autoriser la connexion par clé publique.

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.

La sortie du client en tant que dans ssh -vrévélera qu'il y a un problème à une certaine étape du protocole, mais quand cela est dû à quelque chose sur le serveur, le client ne sera pas informé de la cause. Consultez les fichiers journaux du serveur pour savoir ce qui ne va pas. Vous aurez probablement besoin de rootposséder des autorisations pour le faire. Par exemple, pour un utilisateur sshdconfiguré 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 défaut (stupide) defaultde 0002. Cela signifie que l'accès en écriture pour le groupe. (Nom du groupe = nom d'utilisateur, mais quand même.) Le démon SSH ne fera pas confiance aux fichiers qui peuvent être altérés par des utilisateurs autres que l'utilisateur (enfin, bien rootsû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

Je viens de me faire piéger dans le même problème d'accès avec Fedora Core 16 à 5,5 5,5

les bûches et les commentaires détaillés étaient exactement les mêmes

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

Un autre mordu par ça. Après une longue recherche, il s'est avéré que je fournissais explicitement à ssh la clé publique (avec l'option -i) au lieu de la clé privée. Doh!