Question Pourquoi est-ce que je reçois une «autorisation refusée (publickey)» lorsque j'essaie de passer à SSH depuis Ubuntu local vers un serveur Amazon EC2?


J'ai une instance d'une application s'exécutant dans le nuage sur une instance Amazon EC2 et je dois la connecter à partir de mon Ubuntu local. Cela fonctionne bien sur l'un des ubuntu local et aussi un ordinateur portable. J'ai reçu le message "Autorisation refusée (publickey)" lorsque j'essayais d'accéder à SSH vers EC2 sur un autre Ubuntu local. C'est si étrange pour moi.

Je pense que certains problèmes avec les paramètres de sécurité sur Amazon EC2 ont un accès IP limité à une instance ou qu'un certificat peut avoir besoin d'être régénéré.

Est-ce que quelqu'un connaît une solution?


213
2017-07-13 07:38


origine


"Cela fonctionnait avant" - avant quoi? - womble♦
J'ai une instance Elastic Beanstalk EC2. En août 2013, la solution consistait à accéder à l'instance en tant qu'utilisateur ec2, ce qui avait permis d'éliminer l'erreur Permission Denied (publicKey). Voir: ssh -i ./mike-key-pairoregon.pem ec2-user@ec2-some-address.us-west-2.compute.amazonaws.com. Bien sûr, vous devez tous les autres trucs selon stackoverflow.com/questions/4742478/… - mikemay
Vous obtenez ce problème si le nom d'utilisateur spécifié est incorrect. Les docs aws (docs.aws.amazon.com/AWSEC2/latest/UserGuide/…) donne actuellement un exemple avec le nom d'utilisateur ec2-user [ssh -i /path/my-key-pair.pem ec2-user@ec2-198-51-100-1.compute-1.amazonaws.com], alors que my ( old) ubuntu box a un nom d'utilisateur ubuntu, donc lorsque j'ai utilisé l'exemple, j'ai reçu cette erreur, le changement du nom d'utilisateur correct a été résolu. - david.barkhuizen
@ david.barkhuizen, votre commentaire m'a aidé. J'avais un problème similaire; il s'est avéré que cela avait à voir avec le nom d'utilisateur. Merci. - NaijaProgrammer


Réponses:


La première chose à faire dans cette situation est d’utiliser le -v option de sshafin 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?


140
2017-07-13 07:44



J'ai copié la clé privée ssh sur l'autre machine, comme l'a suggéré @Greg. Ça fonctionne maintenant. Merci! - Vorleak Chy
Pour votre information, vous pouvez utiliser l’option -i pour indiquer le chemin des clés sans les installer. - Jorge Vargas
Dans mon cas, j'utilisais un fichier bitamii .ami et je ne réalisais pas que vous deviez vous connecter en tant qu'utilisateur appelé bitnami, par exemple: ssh -i <keyfile> bitname@<ec2-address>. Malheureusement le -v Cette option ne m’a pas aidé à trouver ça, mais c’est quand même très utile de vérifier! - Matt Connolly
Dans mon cas, j’utilisais un mauvais nom d’utilisateur. utilisait "ubuntu" au lieu de "bitnami". comme ceci: ssh -i key.pem bitnami @ hostaddress - Lucas Pottersky
Un bon prospect est également le nœud distant lui-même, examinez /var/log/auth.log, parfois, vous verrez les messages suivants: Authentication refused: bad ownership or modes for file /var/lib/jenkins/.ssh/authorized_keys ou autre chose - Jonas Libbrecht


Comme il n’a pas été explicitement mentionné, sshd est par défaut très strict sur les autorisations pour authorized_keys des dossiers. Donc si authorized_keys est 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 (sauf si sshd est configuré avec StrictModes no)

Ce que je veux dire par "peut être rendu accessible en écriture" est que, si l'un des répertoires parent est accessible en écriture à une 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 allowed_keys.

Cela ne se présentera pas avec ssh -v, ça va apparaître dans les logs émis par sshd (généralement mis en /var/log/secure ou /var/log/auth.log, dépend de la distribution et syslogd configuration).

De l'homme sshd (8):

 ~/.ssh/authorized_keys
         Lists the public keys (RSA/DSA) that can be used for logging in
         as this user.  The format of this file is described above.  The
         content of the file is not highly sensitive, but the recommended
         permissions are read/write for the user, and not accessible by
         others.

         If this file, the ~/.ssh directory, or the user's home directory
         are writable by other users, then the file could be modified or
         replaced by unauthorized users.  In this case, sshd will not
         allow it to be used unless the StrictModes option has been set to
         “no”.

73
2018-01-05 14:38



Ce bit "peut être rendu en écriture" est ce qui m'a fait - wmarbut
FWIW les autorisations correctes pour les fichiers de clé sont 600 (voir ici) - Matt Lyons
Oui, mon fichier .authorized_keys était inscriptible par groupe, donc il a refusé. - Aditya M P
Je frappais ma tête contre le mur! Mon dossier utilisateur avait les mauvaises autorisations. Je vous remercie! - XJones
Il en va de même pour le dossier ~ / .ssh lui-même. vous pouvez obtenir le message d'erreur suivant: Authentication refused: bad ownership or modes for directory - Yevgeniy M.


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


37
2018-04-01 21:51



ssh host -l user est le même que ssh user@host, droite? - Znarkus
@ Znarkus oui, c'est la même chose. - cregox
Oui, cela a résolu mon problème en causant l'erreur "Permission denied (publickey)". - Brooks Moses
C'était le problème pour moi. Je m'attendais à ce que l'utilisateur "root" fonctionne, mais j'utilisais une image Ubuntu EC2 avec l'utilisateur par défaut "ubuntu". - Cerin


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

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


19
2017-11-17 16:29



Oui ... je courais la commande avec sudo, ce qui explique pourquoi cela n'a pas fonctionné. - thaddeusmt


Quelque chose de plus facile à lire que ssh -i (à 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, en essayant de vous connecter. Il montrera les erreurs en texte brut.

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

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


16
2018-02-01 14:07



Je pense que tu voulais dire -v - Tim Tisdall
c'est le journal du serveur. pour RHEL / CentOS 7: tail -f /var/log/secure - Gianfranco P.


Vérifier votre / etc / ssh / sshd_config fichier. Là, trouver 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

11
2017-12-10 06:15



Cela rendrait le serveur moins sécurisé. - Znarkus
C'était le problème que j'avais: je voulais créer un compte pour un autre utilisateur en m'authentifiant avec juste un mot de passe. Je voulais aussi pouvoir me connecter en tant que moi-même depuis des endroits où je n'avais pas ma clé privée. - Daniel
Comment pouvons-nous aller à /etc/ssh/sshd_config - Si nous ne pouvons même pas entrer dans le serveur? - kyo
Pour accéder au serveur lui-même, vous devez utiliser le fichier PEM qu’ils ont distribué lors de la création de l’instance. Les instructions vont après cela. - Sudipta Chatterjee
Cela a fonctionné pour moi, bien que le redémarrage de sshd ait nécessité la commande suivante: sudo service sshd reload - pacoverflow


Peut-être pas pertinent pour l'affiche actuelle, mais pourrait aider les autres qui le trouvent en cherchant des réponses à des situations similaires. Au lieu de laisser Amazon générer la paire de clés ssh, je vous recommande de télécharger votre propre clé publique ssh standard par défaut sur Amazon et de l'indiquer lorsque vous exécutez une instance EC2.

Cela vous permet de supprimer la syntaxe de type "-i" dans ssh, d'utiliser rsync avec des options standard et 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 vers Amazon EC2
http://alestic.com/2010/10/ec2-ssh-keys


6
2017-09-29 21:15



+1 regardé cette question exactement pour cette raison. - John Riselvato
Je vois cette erreur en suivant votre article. regions = $ (ec2-describe-regions | cut -f2) Option requise '-K, --private-key KEY' manquante (-h pour l'utilisation) - KashifAli
@KashifAli Vous voudrez peut-être configurer les informations d'identification de l'outil de ligne de commande de l'API EC2 pour ne pas avoir à toujours les transmettre sur chaque ligne de commande. - Eric Hammond