it-swarm-fr.com

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?

217
Vorleak Chy

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?

143
Greg Hewgill

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 indique LogLevel DEBUG quelque part. Rechargez le serveur SSH en utilisant le mécanisme fourni par la distribution. (service sshd reload sur 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.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 de rétablir la modification sur /etc/ssh/sshd_config lorsque vous avez terminé!

76
Kjetil Joergensen

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.

37
pkmk

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.

19
user60587

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

16
Znarkus

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
10
Sudipta Chatterjee

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

6
Eric Hammond

É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.

5
Patrick Collins

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.

2
Naftuli Kay

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!

2
uichin

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.

1
Ajit Verma

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.

1
Cian

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.

1
chichilatte

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>.

0
Jacob Tomlinson

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

0
Reese