Pourquoi est-ce que j'obtiens "Autorisation refusée (publickey)" lorsque j'essaie de SSH depuis Ubuntu local vers un serveur Amazon EC2?
J'ai une instance d'une application exécutée dans le cloud sur une instance Amazon EC2, et je dois la connecter à partir de mon Ubuntu local. Cela fonctionne bien sur l'un des ubuntu locaux et également sur un ordinateur portable. J'ai reçu le message "Autorisation refusée (publickey)" en essayant d'accéder à SSH à EC2 sur un autre Ubuntu local. C'est tellement étrange pour moi.
Je pense qu'une sorte de problème avec les paramètres de sécurité sur Amazon EC2 qui a un accès IP limité à une instance ou à un certificat peut avoir besoin de se régénérer.
Quelqu'un connaît-il une solution?
La première chose à faire dans cette situation est d'utiliser le -v pour ssh, afin que vous puissiez voir quels types d'authentification sont essayés et quel est le résultat. Est-ce que cela aide à é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?
Comme il 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 accessible en écriture pour toute personne autre que l'utilisateur ou peut être rendu accessible en écriture par toute personne 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 touches_autorisées.
De plus, si le /home/username/.ssh le répertoire n'appartient pas à l'utilisateur, et donc l'utilisateur n'a pas l'autorisation de lire la clé que 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 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 journal sur DEBUG.
- Éditer
/etc/ssh/sshd_config. Vous voulez une ligne qui indiqueLogLevel DEBUGquelque part. Rechargez le serveur SSH en utilisant le mécanisme fourni par la distribution. (service sshd reloadsur RHEL/CentOS/Scientific.) Un rechargement gracieux ne supprimera pas les sessions existantes. - Essayez à nouveau de vous authentifier.
- Déterminez où vos journaux de l'installation d'authentification vont et lisez-les. (IIRC,
/var/log/auth.logsur les distributions basées sur Debian;/var/log/securesur 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 de rétablir la modification sur /etc/ssh/sshd_config lorsque vous avez terminé!
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 arrivé ici à la recherche d'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 il montrait toujours la "permission refusée (publickey)".
Mon problème était que je n'utilisais pas le bon utilisateur. En exécutant le ssh avec ubuntu @ ec2 ... cela a fonctionné comme d'habitude.
Quelque chose de plus facile à lire que ssh -v (à mon avis bien sûr), est tail -f /var/log/auth.log. Cela 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 d'utilisateurs n'est répertorié dans AllowGroups
Vérifiez votre fichier / etc/ssh/sshd_config. Là, trouvez la ligne qui dit
PasswordAuthentication no
Cette ligne doit être modifiée pour dire oui au lieu de non. Redémarrez également le serveur sshd par la suite.
Sudo /etc/init.d/ssh restart
Peut-être pas pertinent pour l'affiche actuelle, mais pourrait aider ceux qui le trouvent lors de la recherche de réponses à des situations similaires. Au lieu de laisser Amazon générer la paire de clés ssh, je recommande de télécharger votre propre clé ssh publique par défaut standard sur Amazon et de le spécifier lorsque vous exécutez une instance EC2.
Cela vous permet de supprimer la syntaxe de type "-i" dans ssh, d'utiliser rsync avec les options standard, et vous permet également d'utiliser la même clé ssh dans toutes les régions EC2.
J'ai écrit un article sur ce processus ici:
Téléchargement de clés ssh personnelles sur Amazon EC2
http://alestic.com/2010/10/ec2-ssh-keys
Étrangement, mon problème s'est avéré être que le serveur avait été redémarré et qu'un nouveau nom DNS lui avait été attribué. J'utilisais l'ancien nom DNS. Je sais que cela semble stupide, mais cela m'a pris un certain temps pour comprendre cela.
Si vous essayez de vous connecter à un téléphone CyanogenMod exécutant Dropbear, vous devez exécuter les lignes suivantes pour vous assurer que tout est bien autorisé:
chmod 600 /data/dropbear/.ssh/authorized_keys
ou
chmod 700 /data/dropbear/.ssh/authorized_keys # In case of MacOS X 10.6-10.8
et
chmod 755 /data/dropbear/ /data/dropbear/.ssh
Cela m'a corrigé, sinon rien ne peut se connecter.
Si vous utilisez CentOS 5, vous souhaiterez peut-être définir StrictModes no dans /etc/ssh/sshd_config. Je partage le répertoire/home en utilisant NIS/NFS, et j'ai défini toutes les autorisations correctement, mais cela m'a toujours demandé le mot de passe. Après avoir défini StrictModes no, le problème a disparu!
J'avais le même problème même si je suivais censément toutes les étapes, y compris
$ ec2-authorize default -p 22
Cependant, j'avais commencé mon instance dans la région us-west-1. La commande ci-dessus doit donc également spécifier cela.
$ ec2-authorize default -p 22 --region us-west-1
Après cette commande, j'ai pu ssh dans l'instance. J'ai passé un peu de temps avant de réaliser le problème et j'espère que ce message aide les autres.
La réponse de Greg explique comment mieux le résoudre, mais le problème réel est que vous avez une clé ssh définie d'un côté de la transaction (le client), qui tente l'authentification par clé publique plutôt que l'authentification par mot de passe. Comme vous n'avez pas la clé publique correspondante sur l'instance EC2, cela ne fonctionnera pas.
J'ai eu le même problème, et après avoir essayé des tonnes de solutions qui n'ont pas fonctionné, j'ai ouvert le port SSH sur le pare-feu de mon routeur (le panneau de contrôle du pare-feu de mon routeur est un gâchis, il est donc difficile de dire ce qui se passe). Quoi qu'il en soit, cela l'a corrigé :)
Super sanglant ennuyeux que l'erreur que vous obtenez est Autorisation refusée, ce qui implique qu'il y avait une sorte de connexion établie, grr.
Je viens de rencontrer le même problème après avoir ajouté par inadvertance des autorisations d'écriture de groupe au répertoire de base des utilisateurs.
J'ai découvert que c'était la cause en exécutant tail -f /var/log/secure sur la machine et voyant l'erreur Authentication refused: bad ownership or modes for directory /home/<username>.
C'est un cas rare, mais si vous avez activé selinux et que vous utilisez nfs pour le répertoire avec les clés autorisées (par exemple, les répertoires partagés), vous devrez soit désactiver selinux (non recommandé pour des raisons de sécurité, mais vous pouvez le désactiver temporairement pour voir si cela cause le problème) ou autorisez selinux à utiliser les répertoires personnels de nfs. Je ne suis pas clair sur les détails, mais cela a fonctionné pour moi setsebool -P use_nfs_home_dirs 1