Pourquoi est-ce que je reçois une «autorisation refusée (publickey)» lors de la tentative de SSH depuis Ubuntu local vers un serveur Amazon EC2?


218

J'ai une instance d'une application s'exécutant 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 local et aussi un ordinateur portable. J'ai reçu le message "Autorisation refusée (publickey)" lors d'une tentative d'accès à 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?


11
"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 faire face à tous les autres trucs selon stackoverflow.com/questions/4742478/…
mikemay

3
Vous obtenez ce problème si vous avez le mauvais nom d'utilisateur spécifié. Les documents aws ( docs.aws.amazon.com/AWSEC2/latest/UserGuide/… ) donnent 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 ma (ancienne) boîte ubuntu a un nom d'utilisateur ubuntu, donc lorsque j'ai utilisé l'exemple, j'ai reçu cette erreur, le 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:


143

La première chose à faire dans cette situation est d'utiliser l' -voption to sshpour 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?


2
J'ai copié la clé privée ssh sur l'autre machine, comme l'a suggéré @Greg. Ça fonctionne maintenant. Merci!
Vorleak Chy

3
Pour votre information, vous pouvez utiliser le drapeau -i pour indiquer le chemin des clés sans les installer
Jorge Vargas

20
Dans mon cas, je travaillais avec un .ami bitnami et ne savais pas que vous devez vous connecter en tant qu'utilisateur appelé bitnami, comme: ssh -i <keyfile> bitname@<ec2-address>. Malheureusement, l' -voption ne m'a pas aidé à trouver cela, mais c'est quand même très utile à vérifier!
Matt Connolly

7
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

3
Une bonne piste est également le nœud distant lui-même. Regardez /var/log/auth.log, parfois, vous verrez les messages suivants: Authentication refused: bad ownership or modes for file /var/lib/jenkins/.ssh/authorized_keysou autre chose
Jonas Libbrecht

76

Comme il n'a pas été explicitement mentionné, sshd est par défaut très strict sur les permissions pour les authorized_keysfichiers. Donc, si authorized_keysest en écriture pour quelqu'un d'autre que l'utilisateur ou peut être rendu en écriture par quelqu'un d'autre que l'utilisateur, il refusera l'authentification (à moins que sshd ne soit 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.

De plus, si le /home/username/.sshrépertoire n'appartient pas à l'utilisateur et que celui-ci ne dispose donc d'aucune autorisation 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 .sshfichier. Fixez ceci via

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

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

  • Modifier /etc/ssh/sshd_config. Vous voulez une ligne qui se lit LogLevel DEBUGquelque part. Rechargez le serveur SSH en utilisant le mécanisme fourni par la distribution. ( service sshd reloadsur RHEL / CentOS / Scientific.) Un rechargement en douceur ne lâchera 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.logsur les distributions basées sur Debian; /var/log/securesur RHEL / CentOS / Scientific.)

Il est beaucoup plus facile de comprendre ce qui ne va pas avec la sortie de débogage, qui inclut des erreurs d'autorisation de système de fichiers. N'oubliez pas de revenir au changement /etc/ssh/sshd_configlorsque vous avez terminé!


5
Ce peu "peut être fait en écriture" est ce qui m'a eu
wmarbut

7
FWIW les autorisations correctes pour les fichiers de clé sont 600 (voir ici )
Matt Lyons

1
Oui, mon fichier .authorized_keys était inscriptible par groupe, donc il a refusé.
Aditya MP

2
Je frappais ma tête contre le mur! Mon dossier utilisateur avait les mauvaises autorisations. Je vous remercie!
XJones

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

37

J'ai reçu cette erreur, car j'ai oublié d'ajouter une -loption. 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.


25
ssh host -l userest le même que ssh user@host, non?
Znarkus

3
@ Znarkus oui, c'est la même chose.
cregox

Eh oui, cela a résolu mon problème en causant l'erreur "Permission denied (publickey)".
Brooks Moses

1
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

20

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.


Ouais ... J'exécutais la commande sudo, c'est pourquoi cela ne fonctionnait pas.
thaddeusmt

16

Quelque chose de plus facile à lire que ssh -v(à mon avis bien sûr) l’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


c'est le journal du serveur. pour RHEL / CentOS 7:tail -f /var/log/secure
Gianfranco P.

10

Vérifiez votre fichier / etc / ssh / sshd_config . 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 après.

sudo /etc/init.d/ssh restart

18
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

1
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

6

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 sur Amazon EC2
http://alestic.com/2010/10/ec2-ssh-keys


+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 utilisation)
KashifAli

@KashifAli Vous voudrez 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

5

Étrangement, mon problème s'est avéré 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 il m'a fallu un certain temps pour comprendre cela.


Je vous remercie! C'était exactement mon problème. Je n'avais pas réalisé que le nom DNS avait changé lorsque vous redémarriez une instance.
Tim Swast

Dans mon cas, l'URL * .compute.amazonaws.com a changé lorsque j'ai attribué une adresse IP élastique.
Geoffrey Booth

2

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 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 a résolu le problème pour moi, sinon rien ne peut se connecter.


"lorsqu’on essaie d’accéder à SSH vers EC2 sur un autre Ubuntu local."
Grammargeek

1
Et si je n'ai pas authorised_keys ?
IgorGanapolsky

2

Si vous utilisez CentOS 5, vous pouvez définir StrictModes nodans /etc/ssh/sshd_config. Je partage le répertoire / home en utilisant NIS / NFS, et j'ai défini toutes les autorisations correctement, mais le mot de passe m'a toujours été demandé. Après avoir réglé StrictModes no, le problème a disparu!


1

La réponse de Greg explique comment mieux résoudre le problème. Cependant, le problème est que vous avez une clé ssh définie sur un côté de la transaction (le client), qui tente une authentification par clé publique plutôt que par mot de passe. Comme vous n'avez pas la clé publique correspondante sur l'instance EC2, cela ne fonctionnera pas.


2
Comment résoudre le problème?
Julien Grenier

1

J'ai eu le même problème et après avoir essayé des tonnes de solutions qui ne fonctionnaient pas, j'ai ouvert le port SSH du pare-feu de mon routeur (le panneau de configuration du pare-feu de mon routeur est en désordre, il est donc difficile de savoir ce qui se passe). En tout cas, ça a réglé le problème :)

Super sanglant ennuyeux que l'erreur que vous obtenez est la permission refusée, ce qui implique qu'il y avait une sorte de connexion établie, grr.


1

J'avais le même problème même si je suivais supposément toutes les étapes, y compris

$ ec2-authorize default -p 22

Cependant, j'avais commencé mon exemple dans la région us-west-1. Donc, la commande ci-dessus devrait également spécifier cela.

$ ec2-authorize default -p 22 --region us-west-1

Après cette commande, j'ai été en mesure de ssh dans l'instance. J'ai passé un peu de temps avant de comprendre le problème et espère que ce message aidera les autres.


0

C'est un cas rare, mais si vous avez activé selinux et que vous utilisez nfs pour le répertoire avec les authorised_keys (par exemple, les répertoires personnels partagés), vous devrez soit désactiver selinux (non recommandé pour des raisons de sécurité, mais vous pouvez le désactiver temporairement. voir si cela pose problème) ou autoriser selinux à utiliser les répertoires de départ nfs. Je ne suis pas clair sur les détails, mais cela a fonctionné pour moi setsebool -P use_nfs_home_dirs 1


0

Je viens tout juste 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 s'exécutant tail -f /var/log/securesur la machine et en voyant l'erreur Authentication refused: bad ownership or modes for directory /home/<username>.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.