Pourquoi est-ce que je reçois une autorisation refusée (clé publique) lorsque j'essaie de me connecter en SSH d'Ubuntu local à un serveur Amazon EC2 ?

Solution 1 :

La première chose à faire dans cette situation est d'utiliser le -v option à ssh , afin que vous puissiez voir quels types d'authentification sont essayés et quel est le résultat. Cela aide-t-il à éclairer la situation ?

Dans votre mise à jour de votre question, vous mentionnez "sur un autre Ubuntu local". Avez-vous copié la clé privée ssh sur l'autre machine ?

Solution 2 :

Comme cela n'a pas été explicitement mentionné, sshd est par défaut très strict sur les autorisations pour le authorized_keys des dossiers. Donc, si authorized_keys est inscriptible pour toute personne autre que l'utilisateur ou peut être rendu accessible en écriture par quelqu'un d'autre que l'utilisateur, il refusera de s'authentifier (sauf si sshd est configuré avec StrictModes no )

Ce que je veux dire par "peut être rendu accessible en écriture", c'est que si l'un des répertoires parents est accessible en écriture pour toute personne autre que l'utilisateur, les utilisateurs autorisés à modifier ces répertoires peuvent commencer à modifier les autorisations de manière à pouvoir modifier/remplacer les clés_autorisées.

De plus, si le /home/username/.ssh Le répertoire n'appartient pas à l'utilisateur, et donc l'utilisateur n'a pas les permissions de lire la clé, vous pouvez rencontrer des problèmes :

drwxr-xr-x 7 jane jane 4096 Jan 22 02:10 /home/jane
drwx------ 2 root root 4096 Jan 22 03:28 /home/jane/.ssh

Notez que Jane ne possède pas le .ssh dossier. Corrigez cela via

chown -R jane:jane /home/jane/.ssh

Ces types de problèmes d'autorisation de système de fichiers n'apparaîtront pas avec ssh -v , et ils n'apparaîtront même pas dans les journaux sshd (!) tant que vous n'aurez pas défini le niveau de journalisation sur DEBUG.

• Modifier /etc/ssh/sshd_config . Vous voulez une ligne qui lit LogLevel DEBUG là-dedans quelque part. Rechargez le serveur SSH en utilisant le mécanisme fourni par la distribution. (service sshd reload sur RHEL/CentOS/Scientific.) Un rechargement progressif ne supprimera pas les sessions existantes.
• Essayez de vous authentifier à nouveau.
• Déterminez où vont les journaux de votre installation d'authentification et lisez-les. (IIRC, /var/log/auth.log sur les distributions basées sur Debian ; /var/log/secure sur RHEL/CentOS/Scientific.)

Il est beaucoup plus facile de déterminer ce qui ne va pas avec la sortie de débogage qui inclut les erreurs d'autorisation du système de fichiers. N'oubliez pas d'annuler la modification en /etc/ssh/sshd_config une fois terminé !

Solution 3 :

J'ai reçu cette erreur, car j'ai oublié d'ajouter -l option. Mon nom d'utilisateur local n'était pas le même que sur le système distant.

Cela ne répond pas à votre question, mais je suis venu chercher une réponse à mon problème.

Solution 4 :

J'ai reçu ce message sur une nouvelle instance basée sur l'AMI Ubuntu. J'utilisais l'option -i pour fournir le PEM, mais il affichait toujours le message "Autorisation refusée (clé publique)".

Mon problème était que je n'utilisais pas le bon utilisateur. En exécutant le ssh avec [email protected], cela a fonctionné normalement.

Solution 5 :

Quelque chose de plus facile à lire que ssh -v (à mon avis bien sûr), est tail -f /var/log/auth.log . Cela devrait être exécuté sur le serveur auquel vous essayez de vous connecter, tout en essayant de vous connecter. Il affichera les erreurs en texte brut.

Cela m'a aidé à résoudre mon problème :

L'utilisateur [nom d'utilisateur] de xx.yy.com n'est pas autorisé car aucun des groupes d'utilisateurs n'est répertorié dans AllowGroups