Permission refusée (publickey). SSH de l'Ubuntu local vers le serveur Amazon EC2

Comme cela n'a pas été explicitement mentionné, sshd est par défaut très strict sur les permissions pour le fichier authorized_keys fichiers. Ainsi, si authorized_keys es accessible en écriture 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 (à moins que sshd ne soit configuré avec le paramètre 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 quelqu'un d'autre que l'utilisateur, les utilisateurs autorisés à modifier ces répertoires peuvent commencer à modifier les permissions de manière à pouvoir modifier/remplacer les authorized_keys.

En outre, si le /home/username/.ssh n'appartient pas à l'utilisateur, et donc l'utilisateur n'a pas les droits pour 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 fichier. Corrigez cela via

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

Ces sortes de problèmes de permission du système de fichiers n'apparaîtront pas avec ssh -v et ils n'apparaîtront même pas dans les journaux de sshd ( !) tant que vous n'aurez pas réglé le niveau du journal sur DEBUG.

• Modifier /etc/ssh/sshd_config . Vous voulez une ligne qui dit 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 en douceur ne supprimera pas les sessions existantes.
• Essayez de vous authentifier à nouveau.
• Déterminez où se trouvent les journaux de votre installation d'authentification et lisez-les. (IIRC, /var/log/auth.log sur les distros basées sur Debian ; /var/log/secure sur RHEL/CentOS/Scientific).

Il est beaucoup plus facile de comprendre ce qui ne va pas avec la sortie de débogage qui inclut les erreurs de permission du système de fichiers. N'oubliez pas de revenir sur la modification de /etc/ssh/sshd_config quand c'est fait !

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 ici pour chercher une réponse à mon problème.

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 le message "Permission denied (publickey)" était toujours affiché.

Mon problème était que je n'utilisais pas le bon utilisateur. En lançant le ssh avec ubuntu@ec2... cela a fonctionné normalement.

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

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 de l'utilisateur n'est répertorié dans AllowGroups