ssh n'autorise plus l'authentification par clé publique

Mon ordinateur a récemment cessé d'accepter l'authentification par clé publique entrante. J'ai un bureau ubuntu 11.04 dans lequel je ssh depuis une machine Windows. J'utilise du mastic avec du reconstitution historique. Je peux me connecter mais uniquement avec l'authentification par mot de passe interactif, pas avec ma clé rsa que j'ai configurée.

J'ai déjà vérifié que la clé est répertoriée dans ~ / .ssh / authorized_keys. Comment puis-je résoudre ce problème et que dois-je vérifier?

Si l'authentification par clé publique ne fonctionne pas: assurez-vous que côté serveur, votre répertoire personnel ( ~), le ~/.sshrépertoire et le ~/.ssh/authorized_keysfichier ne sont accessibles en écriture que par leur propriétaire . En particulier, aucun d'entre eux ne doit être accessible en écriture par le groupe (même si l'utilisateur est seul dans le groupe). chmod 755ou chmod 700est ok, chmod 770n'est pas.

Que vérifier en cas de problème:

• Exécutez ssh -vvvpour voir beaucoup de sortie de débogage. Si vous postez une question demandant pourquoi vous ne pouvez pas vous connecter avec ssh, incluez cette sortie (vous pouvez anonymiser les noms d'hôte et d'utilisateur).
• Si vous le pouvez, vérifiez les connexions au serveur /var/log/auth.log.
• Si l'authentification par clé publique ne fonctionne pas, vérifiez à nouveau les autorisations, en particulier le bit de groupe (voir ci-dessus).

J'ai rencontré la même chose et j'ai finalement compris que c'était parce que j'avais chiffré mon répertoire personnel. SSH ne peut pas lire le fichier authorized_keys tant que vous ne vous êtes pas connecté, il vous oblige donc à vous authentifier par mot de passe en premier. Voir la section sur le répertoire personnel chiffré sur le lien suivant:

https://help.ubuntu.com/community/SSH/OpenSSH/Keys#Encrypted_Home_Directory

Si vous vérifiez les autorisations sur les répertoires et qu'il y a un "." juste après eux, alors vous pouvez avoir selinux activé, qui gâchera avec l'échange de clés et par défaut pour l'identification manuelle du mot de passe.

Vous pouvez désactiver SELinux pour dépanner en suivant les instructions ici: http://www.centos.org/docs/5/html/5.1/Deployment_Guide/sec-sel-enable-disable-enforcement.html , ou modifiez simplement le / etc / selinux / config et remplacez-le par "forcer" par "désactivé".

J'espère que cela t'aides.

Je m'assurerais que vos paramètres dans / etc / ssh / sshd_config sont corrects.

Pour forcer l'utilisation de PKI uniquement et pour interdire les mots de passe, trouvez la ligne

#PasswordAuthentication yes 

dans votre fichier, décommentez-le et définissez-le sur

PasswordAuthenticate no

Je voudrais également lire la balance des paramètres pour m'assurer qu'ils ont du sens. En particulier, essayez de vous assurer que vous utilisez des clés RSA car DSA est connu pour être compromis.

Une des causes possibles du problème est que vous avez des clés DSA mais maintenant SSH (apparemment) par défaut requiert des clés RSA. J'ai eu le problème lors de la mise à niveau vers 16.04. Vous pouvez en voir plus ici, mais la réponse courte est d'ajouter ce qui suit à ~/.ssh/config:

PubkeyAcceptedKeyTypes ssh-dss

J'ai résolu ce problème en décommentant "PasswordAuthentication yes" dans / etc / ssh / sshd_config.

En raison d'un besoin de dépannage de la communication entre deux machines différentes, j'avais deux clés privées ~/.sshcôté client.

Au lieu de configurer chaque hôte de serveur avec la clé privée respective ~/.ssh/identitycomme je l'aurais dû, j'ai eu la clé secondaire (et dans ce cas, incorrecte) configurée pour tous les hôtes:

Host *
IdentityFile ~/.ssh/identity_b

La correction a ~/.ssh/identityrésolu le problème:

Host a
IdentityFile ~/.ssh/identity_a
Host b
IdentityFile ~/.ssh/identity_b

J'ai juste eu le même problème, mais changer les autorisations avec chmodn'a pas aidé, car il s'est avéré que je ne possédais pas le ~/.ssh/authorized_keysfichier. Vous pouvez changer la propriété du .sshrépertoire avec:

sudo chown -R "$USER" ~/.ssh

D'une certaine manière, cela a fonctionné pour moi:

root @ kaiser: ~ # vim / etc / ssh / sshd_config

Changer cette ligne de oui à non 28 StrictModes non

Réessayer

sysadmin @ suselinux1: ~> con sysadmin kaiser Bienvenue dans Ubuntu 12.04.1 LTS (GNU / Linux 3.2.0-25-i686 générique)

• Documentation: https://help.ubuntu.com/

Dernière connexion: Ven 9 nov 15:40:11 2012 à partir du 10.1.3.25 sysadmin @ kaiser: ~ $ date vie nov 9 17:53:11 CST 2012 sysadmin @ kaiser: ~ $