Comment modifier la paire de clés de mon instance ec2 dans la console de gestion AWS? Je peux arrêter l'instance, je peux créer une nouvelle paire de clés, mais je ne vois aucun lien pour modifier la paire de clés de l'instance.
Comment modifier la paire de clés de mon instance ec2 dans la console de gestion AWS? Je peux arrêter l'instance, je peux créer une nouvelle paire de clés, mais je ne vois aucun lien pour modifier la paire de clés de l'instance.
Réponses:
Cette réponse est utile dans le cas où vous n'avez plus accès SSH au serveur existant (c'est-à-dire que vous avez perdu votre clé privée).
Si vous disposez toujours d'un accès SSH, veuillez utiliser l'une des réponses ci-dessous.
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html#replacing-lost-key-pair
Voici ce que j'ai fait, grâce au blog d'Eric Hammond:
/dev/xvda1
volume (appelons-le volume A) - voir ici/dev/xvdf
(ou /dev/sdf
)SSH sur la nouvelle micro-instance et montez le volume A sur /mnt/tmp
$ sudo mount / dev / xvdf1 / mnt / tmp
Copier ~/.ssh/authorized_keys
vers/mnt/tmp/home/ubuntu/.ssh/authorized_keys
/dev/xvda
.pem
fichierC'est ça.
mkdir /mnt/tmp
puis mount /dev/xvdf /mnt/tmp
devrait faire l'affaire pour # 5. Et n'oubliez pas que l'étape 13. se trouve probablement rm ~/.ssh/known_hosts
sur les boîtes à partir desquelles vous vous connectez.
.ssh/authorized_keys
fichier d' origine .
Une fois qu'une instance a été démarrée, il n'y a aucun moyen de modifier la paire de clés associée à l'instance au niveau des métadonnées, mais vous pouvez modifier la clé ssh que vous utilisez pour vous connecter à l'instance.
Il existe un processus de démarrage sur la plupart des AMI qui télécharge la clé publique ssh et l'installe dans un fichier .ssh / authorized_keys afin que vous puissiez utiliser ssh en tant qu'utilisateur à l'aide de la clé ssh privée correspondante.
Si vous souhaitez modifier la clé ssh que vous utilisez pour accéder à une instance, vous souhaiterez éditer le fichier authorized_keys sur l'instance elle-même et la convertir en votre nouvelle clé publique ssh.
Le fichier authorized_keys se trouve dans le sous-répertoire .ssh du répertoire personnel de l'utilisateur sous lequel vous vous connectez. Selon l'AMI que vous exécutez, il peut s'agir de l'un des éléments suivants:
/home/ec2-user/.ssh/authorized_keys
/home/ubuntu/.ssh/authorized_keys
/root/.ssh/authorized_keys
Après avoir modifié un fichier authorized_keys, utilisez toujours un terminal différent pour confirmer que vous êtes en mesure de vous connecter à l'instance avant de vous déconnecter de la session que vous utilisez pour modifier le fichier. Vous ne voulez pas vous tromper et vous exclure complètement de l'instance.
Pendant que vous songez à des paires de clés ssh sur EC2, je vous recommande de télécharger votre propre clé publique ssh sur EC2 au lieu de laisser Amazon générer la paire de clés pour vous.
Voici un article que j'ai écrit à ce sujet:
Téléchargement de clés ssh personnelles sur Amazon EC2
http://alestic.com/2010/10/ec2-ssh-keys
Cela ne s'appliquerait qu'aux nouvelles instances que vous exécutez.
.pem
fichier de clé privée sur mon Mac, mais ssh -i key.pem
ne s'authentifie pas (autorisation refusée (publickey)). Dans la console de gestion EC2, sous Nom de la paire de clés, il ne répertorie rien. C'est alarmant pour moi. Comment puis-je régler cela? Il semble basé sur la console de gestion qu'aucune paire de clés que j'ai configurée n'a été affectée à l'instance!
Exécutez cette commande après avoir téléchargé votre pem AWS.
ssh-keygen -f YOURKEY.pem -y
Vider ensuite la sortie dans authorized_keys
.
Ou copiez le fichier pem sur votre instance AWS et exécutez les commandes suivantes
chmod 600 YOURKEY.pem
et alors
ssh-keygen -f YOURKEY.pem -y >> ~/.ssh/authorized_keys
Instruction du support AWS EC2:
cela sauvera le fichier updated_keys mis à jour
essayez maintenant d'ouvrir une nouvelle session SSH sur votre instance en utilisant votre nouvelle clé de paiement
Lorsque vous avez confirmé que vous pouvez SSH dans l'instance à l'aide de la nouvelle paire de clés, vous pouvez vi .ssh / authorized_key et supprimer l'ancienne clé.
Réponse à la remarque de Shaggie:
Si vous ne parvenez pas à vous connecter à l'instance (par exemple, la clé est corrompue), utilisez la console AWS pour détacher le volume ( http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-detaching-volume.html ) et le rattacher à l'instance de travail, puis changer la clé sur le volume et le rattacher à l'instance précédente.
J'ai remarqué que lorsque géré par Elastic Beanstalk, vous pouvez changer votre paire de clés EC2 active. Sous Elastic Beanstalk> Configuration> Sécurité, choisissez la nouvelle clé dans la liste déroulante Paire de clés EC2 . Vous verrez ce message vous demander si vous êtes sûr:
EC2KeyName: les modifications apportées aux paramètres de l'option EC2KeyName ne prendront pas effet immédiatement. Chacune de vos instances EC2 existantes sera remplacée et vos nouveaux paramètres prendront alors effet.
Mon instance était déjà terminée lorsque je l'ai fait. Il a ensuite démarré, terminé et recommencé. Apparemment, «remplacer» signifie terminer et créer une nouvelle instance. Si vous avez modifié votre volume de démarrage, créez d'abord une AMI, puis spécifiez cette AMI dans le même formulaire Elastic Beanstalk> Configuration> Instances que l' ID AMI personnalisé . Cela met également en garde contre le remplacement des instances EC2.
Après avoir modifié votre paire de clés EC2 et votre ID AMI personnalisé, et après avoir vu des avertissements sur les deux, cliquez sur Enregistrer pour continuer.
N'oubliez pas que l'adresse IP change lorsque l'instance est recréée, vous devrez donc récupérer une nouvelle adresse IP à partir de la console EC2 pour l'utiliser lors de la connexion via SSH.
J'ai suivi cette approche et, après un certain temps, j'ai réussi à la faire fonctionner. L'absence de commandes réelles a rendu la tâche difficile, mais je l'ai compris. CEPENDANT - une approche beaucoup plus facile a été trouvée et testée peu de temps après:
Si les étapes ci-dessous sont suivies, cela vous fera gagner beaucoup de temps et il ne sera pas nécessaire d'arrêter l'instance en cours d'exécution.
C'est ça. Profitez :)
Je crois que l'approche la plus simple consiste à:
Si vous utilisez la plate-forme ElasticBeanstalk, vous pouvez modifier les clés en allant:
Cela mettra fin à l'instance actuelle et en créera une nouvelle avec les clés / paramètres choisis.
Il y a deux scénarios posés dans cette question: -
1) Vous n'avez pas accès au fichier .pem, c'est pourquoi vous souhaitez en créer un nouveau.
2) Vous avez le. accès au fichier pem avec vous, mais vous souhaitez simplement modifier ou créer un nouveau fichier .pem à des fins de vulnérabilité ou de sécurité .
Donc, si vous avez perdu vos clés, vous pouvez faire défiler vers le haut et voir d'autres réponses . Mais si vous changez simplement votre fichier .pem pour des raisons de sécurité, suivez les étapes: -
1) Accédez à la connexion à la console AWS et créez un nouveau fichier .pem à partir de la section de paire de clés là-bas. Il sera automatiquement téléchargé le fichier .pem sur votre PC
2) changez l'autorisation en 400 si vous utilisez Linux / ubuntu appuyez sur la commande ci-dessous
chmod 400 yournewfile.pem
3) Générez le RSA du fichier nouvellement téléchargé sur votre machine locale
ssh-keygen -f yournewfile.pem -y
4) Copiez le code RSA d'ici
5) Maintenant, SSH sur votre instance via le fichier .pem précédent
ssh -i oldpemfileName.pem username@ipaddress
sudo vim ~/.ssh/authorized_keys
6) Donnez un espace de deux lignes et collez le RSA copié du nouveau fichier ici, puis enregistrez le fichier
7) Maintenant, votre nouveau fichier .pem est lié à l'instance en cours d'exécution
8) Si vous souhaitez désactiver l'accès au fichier .pem précédent, modifiez simplement
sudo vim ~/.ssh/authorized_keys
déposer et supprimer ou modifier le RSA précédent à partir d'ici.
Remarque: - Retirez soigneusement afin que le RSA nouvellement créé ne soit pas modifié.
De cette façon, vous pouvez modifier / connecter le nouveau fichier .pem à votre instance en cours d'exécution.
Vous pouvez révoquer l'accès au fichier .pem généré précédemment pour des raisons de sécurité.
J'espère que cela aiderait!
La solution la plus simple consiste à copier le contenu de
~/.ssh/id_rsa.pub
dans les clés autorisées de votre instance AWS à
~/.ssh/authorized_keys
Cela vous permettra de ssh dans l'instance EC2 sans spécifier de fichier pem pour la commande ssh. Vous pouvez supprimer toutes les autres clés une fois que vous avez testé la connexion à celui-ci.
Si vous devez créer une nouvelle clé pour la partager avec quelqu'un d'autre, vous pouvez le faire avec:
ssh-keygen -t rsa
qui va créer le fichier private key.pem, et vous pouvez obtenir la clé publique de celui-ci avec:
ssh-keygen -f private_key.pem -y > public_key.pub
Toute personne possédant private_key.pem pourra se connecter avec
ssh user@host.com -i private_key.pem
~/.ssh/authorized_keys
lorsque je ne peux même pas l'instance aws SSH?
Vous n'avez pas besoin de faire pivoter le périphérique racine et de modifier la clé publique SSH authorized_keys
. Pour cela, vous pouvez utiliser les données utilisateur pour vous ajouter des clés ssh à n'importe quelle instance. Pour cela, vous devez d'abord créer un nouveau KeyPair à l'aide de la console AWS ou via ssh-keygen.
ssh-keygen -f YOURKEY.pem -y
Cela va générer une clé publique pour votre nouveau KeyHair SSH, copier cette clé publique et l'utiliser dans le script ci-dessous.
Content-Type: multipart/mixed; boundary="//"
MIME-Version: 1.0
--//
Content-Type: text/cloud-config; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="cloud-config.txt"
#cloud-config
cloud_final_modules:
- [scripts-user, always]
--//
Content-Type: text/x-shellscript; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="userdata.txt"
#!/bin/bash
/bin/echo "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC6xigPPA/BAjDPJFflqNuJt5QY5IBeBwkVoow/uBJ8Rorke/GT4KMHJ3Ap2HjsvjYrkQaKANFDfqrizCmb5PfAovUjojvU1M8jYcjkwPG6hIcAXrD5yXdNcZkE7hGK4qf2BRY57E3s25Ay3zKjvdMaTplbJ4yfM0UAccmhKw/SmH0osFhkvQp/wVDzo0PyLErnuLQ5UoMAIYI6TUpOjmTOX9OI/k/zUHOKjHNJ1cFBdpnLTLdsUbvIJbmJ6oxjSrOSTuc5mk7M8HHOJQ9JITGb5LvJgJ9Bcd8gayTXo58BukbkwAX7WsqCmac4OXMNoMOpZ1Cj6BVOOjhluOgYZbLr" >> /home/hardeep/.ssh/authorized_keys
--//
Après le redémarrage, la machine aura la clé de publication SSH spécifiée. Supprimez les données utilisateur après le premier redémarrage. En savoir plus sur les données utilisateur au démarrage .
Avertissement: N'oubliez pas d'effacer à nouveau les données utilisateur. Sinon, cette clé sera poussée à chaque démarrage d'instance. Instructions étape par étape .
#cloud-config
bootcmd:
- echo 'ssh-rsa AAAAB3Nz...' > /root/.ssh/authorized_keys
J'ai essayé les étapes ci-dessous et cela a fonctionné sans arrêter l'instance. Ma condition était - comme j'ai changé ma machine cliente, l'ancien fichier .pem ne me permettait pas de me connecter à l'instance ec2.
Vous verrez vos anciennes clés dans ce fichier.
ssh-keygen -f YOUR_PEM_FILE.pem -y Il va générer une clé. Ajoutez la clé à ~ / .ssh / authorized_keys ouvert à l'étape # 1. Pas besoin de supprimer l'ancienne clé.
À partir de la console AWS, créez une nouvelle paire de clés. Stockez-le dans votre nouvelle machine. Renommez-le en ancien fichier pem - la raison est que l'ancien fichier pem est toujours associé à l'instance ec2 dans AWS.
Terminé.
Je peux me connecter à l'AWS ec2 depuis ma nouvelle machine cliente.
Vous avez plusieurs options pour remplacer la clé de votre instance EC2.
Étant donné que la première option peut être trouvée facilement dans les réponses ou dans le moteur de recherche de votre choix, je veux me concentrer sur le gestionnaire de systèmes.
Systems Manager
Automation
à gauche.Execute Automation
AWSSupport-TroubleshootSSH
(généralement c'est sur la dernière page)Vous pouvez trouver plus d'informations sur la documentation AWS officielle
La réponse de Yegor256 a fonctionné pour moi, mais j'ai pensé que j'ajouterais juste quelques commentaires pour aider ceux qui ne sont pas si doués pour monter des disques (comme moi!):
Amazon vous donne le choix de ce que vous voulez nommer le volume lorsque vous l'attachez. Vous avez utilisé un nom dans la plage de / dev / sda - / dev / sdp Les nouvelles versions d'Ubuntu renommeront alors ce que vous y mettez en / dev / xvd (x) ou quelque chose à cet effet.
Donc pour moi, j'ai choisi / dev / sdp comme nom le nom du montage dans AWS, puis je me suis connecté au serveur, et j'ai découvert qu'Ubuntu avait renommé mon volume en / dev / xvdp1). J'ai ensuite dû monter le lecteur - pour moi, je devais le faire comme ceci:
mount -t ext4 xvdp1 /mnt/tmp
Après avoir sauté à travers tous ces cerceaux, j'ai pu accéder à mes fichiers dans / mnt / tmp
Cela ne fonctionnera que si vous avez accès à l'instance dans laquelle vous souhaitez modifier / ajouter la clé. Vous pouvez créer une nouvelle paire de clés. Ou si vous avez déjà la paire de clés, vous pouvez coller la clé publique de la nouvelle paire dans le fichier authorized_keys sur votre instance.
vim .ssh / authorized_keys
Vous pouvez maintenant utiliser la clé privée de cette paire et vous connecter.
J'espère que cela t'aides.
si vous ne parvenez pas à vous connecter à VM et supprimé vos clés ssh et vous pouvez également modifier la paire de clés de votre ec2 en suivant les étapes ci-dessous. Passez à l'étape 1) arrêtez votre instance ec2. 2) prenez un instantané de la machine virtuelle et du stockage. 3) créez une nouvelle machine virtuelle tout en la créant, sélectionnez votre instantané et créez une VM à partir de votre instantané. 4) tandis que la création de VM télécharge votre paire de clés. 5) une fois votre VM UP vous pouvez ssh avec une nouvelle paire de clés et vos données seront également sauvegardées.
Ce que tu peux faire...
Créez un nouveau profil / rôle d'instance auquel est associée la stratégie AmazonEC2RoleForSSM.
Attachez ce profil d'instance à l'instance.
Merci du conseil les gars. Je les garderai certainement à l'esprit lorsque je devrai reposer les paires de clés. Cependant, dans un souci d'efficacité et de paresse, j'ai trouvé autre chose:
J'espère que cela peut vous être utile et vous faire gagner du temps et minimiser la quantité de cheveux blancs que vous obtenez avec des trucs comme ça :)