"Le serveur a refusé notre clé" après le lancement d'une instance à partir d'une EMI AMI privée
J'ai créé ma propre EMI AMI, partagée avec un autre compte AWS, lancé une nouvelle instance basée sur cette image avec une nouvelle paire de clés et maintenant, lorsque j'essaie de me connecter à cette nouvelle instance, un message d'erreur s'affiche: "Le serveur a refusé notre clé" .
Voici ce que j'ai fait (étape par étape):
- Configuration du nouveau serveur CentOS 6.3 dans mon compte personnel (avec ma paire de clés personnelle)
- Création de l'image AMI EBS de ce serveur
- Partagé cette image avec le compte de mon client
- Lancement d'une nouvelle instance dans mon compte client basé sur cette image partagée + nouvelle paire de clés
- La nouvelle instance lancée ne veut pas prendre une nouvelle paire de clés. Après quelques tests, je suppose qu’il accepte ma paire de clés personnelle à la place.
Comment créer une nouvelle instance à partir de mon image pour accepter de nouvelles paires de clés? J'ai même essayé de supprimer le fichier ".ssh/registered_keys" de l'image d'origine, de lancer une nouvelle instance basée sur cette image sans clé publique et toujours sans succès.
Veuillez indiquer comment créer des images qui ne seraient pas attachées à d'anciennes paires de clés.
J'ai eu un problème similaire avec ce message d'erreur et voici comment je l'ai corrigé. J'espère que cela vous aide, ou à quelqu'un d'autre qui est coincé et trouve son chemin ici:
- Dans la console AWS, assurez-vous que votre instance est saine et en cours d'exécution.
- Vérifiez que vous avez utilisé l'adresse DNS publique correcte, répertoriée lorsque vous cliquez sur une instance
- Sélectionnez Groupes de sécurité dans la partie gauche et cliquez sur le groupe de sécurité que vous souhaitez utiliser.
- Cliquez sur l'onglet Inbound
- Dans la boîte de dialogue Créer une nouvelle règle: sélectionnez SSH
- Dans la source, entrez votre adresse IP et votre valeur CIDR. Si c'est juste que vous n'avez pas de NAT sur votre réseau, utilisez simplement 32 comme CIDR (par exemple.?.?..?.?./32)
- Cliquez sur Ajouter une règle
- Cliquez sur Appliquer les modifications à la règle.
- Faites un clic droit sur votre instance et sélectionnez Créer une image (EBS AMI).
- Donnez-lui un nom d'image dans l'assistant de création d'image, puis cliquez sur Créer.
- Après quelques instants, sélectionnez les AMI dans la barre de navigation de gauche dans la console AWS.
- Cliquez avec le bouton droit sur la nouvelle AMI, puis cliquez sur Lancer l'instance.
- Dans les instances de demande Wizard, cliquez sur Continuer jusqu'à ce que vous deviez créer une paire de clés.
- Choisissez une paire de clés et notez-la (REMARQUE: si vous ne possédez toujours pas votre fichier .pem pour cette paire de clés, vous devrez en générer un nouveau en sélectionnant Paires de clés dans la barre de navigation de gauche, Créer une paire de clés. etc. pour obtenir le fichier .pem)
- Sélectionnez le groupe de sécurité avec la règle que vous avez créée pour votre adresse IP (et CIDR de 32 - pas de masque de sous-réseau)
- Cliquez sur Continuer, puis sur l'écran suivant, cliquez sur Lancer.
- Revenez à la vue Instances et attendez que votre instance soit complètement initialisée et saine.
- Ouvrez PuttyGEN
- Cliquez sur Conversions dans la barre d'outils, puis sur Importer une clé.
- Accédez à votre clé .pem dans le navigateur de fichiers et ouvrez-la.
- Sélectionnez SSH-1 (RSA) dans la zone Paramètres
- Mettez le nom de votre paire de clés dans la case Commentaire de clé (juste pour un bon entretien)
- Cliquez sur Enregistrer la clé privée et enregistrez le fichier .ppk quelque part sur votre système de fichiers.
- Ouvrir Mastic
- Entrez le DNS public de votre instance EC2 dans la zone Nom d'hôte.
- Entrez le port 22
- Cochez le bouton radio SSH dans la zone Type de connexion
- Cliquez sur SSH dans l'arborescence des connexions dans la barre de navigation de gauche.
- Cliquez sur Auth
- Cliquez sur Parcourir dans la zone Paramètres d’authentification et ouvrez votre fichier .ppk.
- Cliquez sur Session dans la barre de navigation de gauche
- Entrez un nom pour cette connexion dans la zone de texte Sessions sauvegardées, puis cliquez sur Enregistrer (vous éviterez ainsi de passer par la connexion PuTTY configurée à chaque fois et vous pourrez simplement double-cliquer sur votre connexion enregistrée - pour les personnes ignorantes)
- Cliquez sur Ouvrir
- Lorsque vous êtes invité à entrer un nom de connexion, vous utiliserez probablement 'ec2-user' ou 'ubuntu' (CONSEIL: utilisez 'root' et vous obtiendrez probablement un message vous indiquant le nom d'utilisateur à utiliser à la place!)
- Pas besoin de mot de passe, le fichier .ppk vous authentifiera
- Espérons que vous êtes maintenant connecté à l'instance EC-2 et que le tour est joué!
J'ai eu ce problème avec une nouvelle instance de SUSE. J'ai enfin pu me connecter en utilisant l'utilisateur 'root'. Il continuait à rejeter ec2-user.
cela signifie que vous n'utilisez pas le nom d'utilisateur correct pour vous connecter à votre instance ec2. Voici la liste des utilisateurs que vous pouvez utiliser dans PuTTY pour vous connecter à une instance ec2 Pour une AMI Amazon Linux, le nom d'utilisateur est ec2-user . Pour une AMI RHEL5, le nom d'utilisateur est soit root. ou ec2-user . Pour une AMI Ubuntu, le nom d'utilisateur est ubuntu . Pour une AMI Fedora, le nom d'utilisateur est Fedora ou ec2- user . Sous SUSE Linux, le nom d'utilisateur est root ou ec2-user . Sinon, si ec2-user et root ne fonctionnent pas, vérifiez auprès de l'AMI. fournisseur.
Puisque votre AMI provient d'une AMI de communauté et non d'une AMI publique officielle, il est possible qu'elle n'ait pas été configurée pour copier les clés ssh au démarrage de l'instance ou qu'elle utilise un mécanisme différent pour le faire.
D'après ce que je comprends, pour que les clés ssh soient copiées au démarrage, un script Shell doit être exécuté à l'intérieur de l'instance elle-même, comme décrit brièvement ici .
La page de description AMI indique qu'elle a été "activée par le cloud", alors il existe peut-être un moyen de le faire via CloudInit. Voir la doc ici .
J'ai eu ce problème et il s'est avéré que je tapais ec2_user alors qu'il était censé être ec2-user
Par défaut, Amazon ajoutera la nouvelle clé à celle existante. Nous pouvons le résoudre en montant le lecteur sur une autre instance active, en supprimant le contenu du fichier .ssh/allowed_keys et en ajoutant le fichier de clés PEM de votre nouvelle clé.
Il ne peut s’agir que d’une seule des raisons de montrer Server Refused notre clé.
C’est-à-dire que la combinaison serveur paire de clés et nom d’utilisateur n’est pas correcte, j’ai fait face à de nombreuses reprises.