AWS Console m'a donné accès à un compte avec 2 instances en cours d'exécution que je ne peux pas fermer (en production). J'aimerais cependant accéder à ces instances par SSH. Est-il possible de créer une nouvelle paire de clés et de l'appliquer aux instances afin que je puisse intégrer SSH? L'obtention du fichier pem existant pour la paire de clés sous laquelle les instances ont été créées n'est actuellement pas une option.
Si ce n'est pas possible, y a-t-il un autre moyen d'entrer dans les instances?
Vous ne pouvez pas appliquer une paire de clés à une instance en cours d'exécution. Vous pouvez uniquement utiliser la nouvelle paire de clés pour lancer une nouvelle instance.
Pour la récupération, s'il s'agit d'une AMI de démarrage EBS, vous pouvez l'arrêter, créer un instantané du volume. Créez un nouveau volume basé sur celui-ci. Et être en mesure de l'utiliser pour démarrer l'ancienne instance, créer une nouvelle image ou récupérer des données.
Bien que les données stockées de manière éphémère soient perdues.
En raison de la popularité de cette question et de cette réponse, je souhaitais capturer les informations contenues dans le lien que Rodney a publié dans son commentaire.
Le crédit va à Eric Hammond pour cette information .
Vous pouvez examiner et modifier des fichiers sur le volume EBS racine d’une instance EC2 même si vous vous trouvez dans une situation que vous considérez comme désastreuse, par exemple:
Sur un ordinateur physique assis à votre bureau, vous pouvez simplement démarrer le système avec un CD ou une clé USB, monter le disque dur, extraire et réparer les fichiers, puis redémarrer l'ordinateur pour qu'il soit de nouveau opérationnel.
Cependant, une instance EC2 distante semble distante et inaccessible lorsque vous vous trouvez dans l'une de ces situations. Heureusement, AWS nous fournit la puissance et la flexibilité nécessaires pour pouvoir restaurer un système comme celui-ci, à condition que nous exécutions des instances de démarrage EBS et non un magasin d'instances.
L’approche sur EC2 est un peu similaire à la solution physique, mais nous allons déplacer et monter le "disque dur" défectueux (volume EBS racine) sur une instance différente, le réparer, puis le remettre en place.
Dans certaines situations, il peut être simplement plus facile de démarrer une nouvelle instance EC2 et de jeter la mauvaise, mais si vous voulez vraiment réparer vos fichiers, voici l'approche qui a fonctionné pour beaucoup:
Configuration
Identifiez l'instance d'origine (A) et le volume contenant le volume EBS racine cassé avec les fichiers à afficher et à modifier.
instance_a=i-XXXXXXXX
volume=$(ec2-describe-instances $instance_a |
egrep '^BLOCKDEVICE./dev/sda1' | cut -f3)
Identifiez la deuxième instance EC2 (B) que vous utiliserez pour réparer les fichiers sur le volume EBS d'origine. Cette instance doit être exécutée dans la même zone de disponibilité que l'instance A pour pouvoir être connectée au volume EBS. Si vous n'avez pas déjà une instance en cours d'exécution, démarrez-en une temporaire.
instance_b=i-YYYYYYYY
Arrêtez l'instance rompue A (attendez son arrêt complet), détachez le volume EBS racine de l'instance (attendez qu'il soit détaché), puis attachez le volume à l'instance B sur un périphérique inutilisé.
ec2-stop-instances $instance_a
ec2-detach-volume $volume
ec2-attach-volume --instance $instance_b --device /dev/sdj $volume
ssh sur l’instance B et montez le volume pour pouvoir accéder à son système de fichiers.
ssh ...instance b...
Sudo mkdir -p 000 /vol-a
Sudo mount /dev/sdj /vol-a
Corrige-le
À ce stade, l'intégralité du système de fichiers racine de l'instance A est disponible pour la visualisation et l'édition sous/vol-a sur l'instance B. Par exemple, vous souhaiterez peut-être:
Remarque: Les identifiants utilisateur des deux instances peuvent ne pas être identiques. Soyez donc vigilant si vous créez, modifiez ou copiez des fichiers appartenant à des utilisateurs non root. Par exemple, votre utilisateur mysql sur l’instance A peut avoir le même UID que votre utilisateur postfix sur l’instance B, ce qui pourrait poser problème si vous chowniez des fichiers portant un seul nom, puis que vous remettez le volume sur A.
Conclusion
Une fois que vous avez terminé et que vous êtes satisfait des fichiers sous/vol-a, démontez le système de fichiers (toujours sur instance-B):
Sudo umount /vol-a
Sudo rmdir /vol-a
Maintenant, revenez sur votre système avec ec2-api-tools, continuez à déplacer le volume EBS à son emplacement d'origine sur l'instance d'origine A et redémarrez l'instance:
ec2-detach-volume $volume
ec2-attach-volume --instance $instance_a --device /dev/sda1 $volume
ec2-start-instances $instance_a
J'espère que vous avez résolu le problème, que l'instance A se présente très bien et que vous pouvez accomplir ce que vous aviez initialement prévu de faire. Sinon, vous devrez peut-être continuer à répéter ces étapes jusqu'à ce que tout fonctionne.
Remarque: Si vous avez attribué une adresse IP Elastic à l'instance A lors de son arrêt, vous devrez la réassocier après l'avoir redémarrée.
Rappelles toi! Si votre instance B a été démarrée temporairement juste pour ce processus, n’oubliez pas de la terminer maintenant.
Bien que vous ne puissiez pas ajouter directement une paire de clés à une instance EC2 en cours d'exécution, vous pouvez créer un utilisateur linux et créer une nouvelle paire de clés pour elle, puis l'utiliser comme vous le feriez avec la paire de clés de l'utilisateur d'origine.
Dans votre cas, vous pouvez demander au propriétaire de l'instance (qui l'a créée) de procéder comme suit. Ainsi, le propriétaire de l'instance n'a pas besoin de partager ses propres clés avec vous, mais vous pourrez quand même utiliser SSH dans ces instances. Ces étapes ont été à l'origine publiées par Utkarsh Sengar (alias. @ zengr ) sur http://utkarshsengar.com/2011/01/manage-multiple-accounts-on-1-Amazon- ec2-instance / . Je n'ai fait que quelques petits changements.
Étape 1: connectez-vous par défaut à l'utilisateur “ubuntu” :
$ ssh -i my_orig_key.pem [email protected]
Étape 2: créez un nouvel utilisateur, nous appellerons notre nouvel utilisateur "john" :
[ubuntu@ip-11-111-111-111 ~]$ Sudo adduser john
Définir le mot de passe pour “john” par:
[ubuntu@ip-11-111-111-111 ~]$ Sudo su -
[root@ip-11-111-111-111 ubuntu]# passwd john
Ajouter "john" à la liste de sudoer en:
[root@ip-11-111-111-111 ubuntu]# visudo
.. et ajoutez ce qui suit à la fin du fichier:
john ALL = (ALL) ALL
Bien! Nous avons créé notre nouvel utilisateur. Vous devez maintenant générer le fichier de clé qui sera nécessaire pour vous connecter, comme nous avons my_orin_key.pem à l’étape 1.
Maintenant, sortez et revenez à ubuntu, en root.
[root@ip-11-111-111-111 ubuntu]# exit
[ubuntu@ip-11-111-111-111 ~]$
Étape 3: création des clés publique et privée :
[ubuntu@ip-11-111-111-111 ~]$ su john
Entrez le mot de passe que vous avez créé pour "john" à l'étape 2. Créez ensuite une paire de clés. N'oubliez pas que la phrase secrète de la paire de clés doit comporter au moins 4 caractères.
[john@ip-11-111-111-111 ubuntu]$ cd /home/john/
[john@ip-11-111-111-111 ~]$ ssh-keygen -b 1024 -f john -t dsa
[john@ip-11-111-111-111 ~]$ mkdir .ssh
[john@ip-11-111-111-111 ~]$ chmod 700 .ssh
[john@ip-11-111-111-111 ~]$ cat john.pub > .ssh/authorized_keys
[john@ip-11-111-111-111 ~]$ chmod 600 .ssh/authorized_keys
[john@ip-11-111-111-111 ~]$ Sudo chown john:ubuntu .ssh
Dans l'étape ci-dessus, john est l'utilisateur que nous avons créé et ubuntu est le groupe d'utilisateurs par défaut.
[john@ip-11-111-111-111 ~]$ Sudo chown john:ubuntu .ssh/authorized_keys
Étape 4: il ne vous reste plus qu'à télécharger la clé appelée "john" . J'utilise scp pour télécharger/télécharger des fichiers depuis EC2, voici comment vous pouvez le faire.
Vous aurez toujours besoin de copier le fichier en utilisant ubuntu user, car vous ne disposez que de la clé pour ce nom d'utilisateur. Vous devrez donc déplacer la clé dans le dossier Ubuntu et la chmod vers 777.
[john@ip-11-111-111-111 ~]$ Sudo cp john /home/ubuntu/
[john@ip-11-111-111-111 ~]$ Sudo chmod 777 /home/ubuntu/john
Maintenant, venez au terminal de la machine locale, où vous avez le fichier my_orig_key.pem et faites ceci:
$ cd ~/.ssh
$ scp -i my_orig_key.pem [email protected]:/home/ubuntu/john john
La commande ci-dessus va copier la clé "john" dans le répertoire de travail actuel sur votre machine locale. Une fois la clé copiée sur votre ordinateur local, supprimez "/ home/ubuntu/john", car il s’agit d’une clé privée.
Maintenant, votre machine locale chmod john à 600.
$ chmod 600 john
Étape 5: Il est temps de tester votre clé :
$ ssh -i john [email protected]
Ainsi, de cette manière, vous pouvez configurer plusieurs utilisateurs pour qu’ils utilisent une seule instance EC2!
Sur votre ordinateur local, exécutez la commande:
ssh-keygen -t rsa -C "SomeAlias"
Une fois cette commande exécutée, un fichier se terminant par * .pub sera généré. Copiez le contenu de ce fichier.
Sur la machine Amazon, éditez ~/.ssh/registered_keys et collez le contenu du fichier * .pub (et supprimez d’abord le contenu existant).
Vous pouvez ensuite SSH en utilisant l'autre fichier généré à partir de la commande ssh-keygen (la clé privée).
Cela m'est arrivé plus tôt (je n'avais pas accès à une instance EC2 créée par quelqu'un d'autre, mais j'avais accès à la console Web AWS) et j'ai blogué la réponse suivante: http://readystate4.com/2013/04/09/ aws-gaining-ssh-access-to-an-ec2-instance-you-lost-access-to /
En gros, vous pouvez détacher le lecteur EBS, le connecter à un EC2 auquel vous avez accès. Ajoutez votre clé de publication SSH à ~ec2-user/.ssh/authorized_keys
sur ce lecteur connecté. Puis remettez-le sur l'ancienne instance EC2. pas à pas dans le lien utilisant Amazon AMI.
Pas besoin de créer des instantanés ou de créer une nouvelle instance clonée.
Dans mon cas, j’ai utilisé cette documentation pour associer une paire de clés à mon instance d’Elastic Beanstalk.
Important
Vous devez créer une paire de clés Amazon EC2 et configurer vos instances Amazon EC2 provisionnées par Elastic Beanstalk afin qu'elles utilisent la paire de clés Amazon EC2 avant de pouvoir accéder à vos instances Amazon EC2 provisionnées par Elastic Beanstalk. Vous pouvez configurer vos paires de clés Amazon EC2 à l'aide de AWS Management Console. Pour obtenir des instructions sur la création d'une paire de clés pour Amazon EC2, consultez le Guide de démarrage Amazon Elastic Compute Cloud.
Configuration d'instances de serveur Amazon EC2 avec Elastic Beanstalk
Je n'ai pas trouvé de moyen facile d'ajouter une nouvelle paire de clés via la console, mais vous pouvez le faire manuellement.
Il suffit de ssh dans votre boîte EC2 avec la paire de clés existante. Puis éditez le ~/.ssh/registered_keys et ajoutez la nouvelle clé sur une nouvelle ligne. Quittez et ssh via la nouvelle machine. Succès!
Vous pouvez simplement ajouter une nouvelle clé à l'instance à l'aide de la commande suivante:
ssh-copy-id -i ~/.ssh/id_rsa.pub domain_alias
Vous pouvez configurer domain_alias dans ~/.ssh config
Host domain_alias
User ubuntu
Hostname domain.com
IdentityFile ~/.ssh/ec2.pem
Une fois l’instance lancée, il n’ya aucun moyen de modifier la paire de clés associée à l’instance au niveau métadonnées, mais vous pouvez modifier la clé ssh que vous utilisez pour vous connecter à l’instance .
stackoverflow.com/questions/7881469/change-key-pair-for-ec2-instance