amazon web services - publickey - Añadir Keypair a la instancia existente de EC2

permission denied(publickey) aws (8)

Una vez que se ha iniciado una instancia, no hay forma de cambiar el par de llaves asociado con la instancia a nivel de metadatos, pero puede cambiar la clave ssh que usa para conectarse a la instancia .

stackoverflow.com/questions/7881469/change-key-pair-for-ec2-instance

Me dieron acceso a la Consola AWS a una cuenta con 2 instancias en ejecución que no puedo cerrar (en producción). Sin embargo, me gustaría obtener acceso SSH a estas instancias, ¿es posible crear un nuevo par de llaves y aplicarlo a las instancias para poder ingresar SSH? Obtener el archivo pem existente para el par de llaves en el que se crearon las instancias actualmente no es una opción.

Si esto no es posible, ¿hay alguna otra forma en que pueda entrar en los casos?

Aunque no puede agregar un par de claves a una instancia de EC2 en ejecución directamente, puede crear un usuario de Linux y crear un nuevo par de claves para él, luego usarlo como lo haría con el par de claves del usuario original.

En su caso, puede pedirle al propietario de la instancia (quien lo creó) que haga lo siguiente. Por lo tanto, el propietario de la instancia no tiene que compartir sus propias claves con usted, pero aún así podría tener acceso a estas instancias. Estos pasos fueron publicados originalmente por Utkarsh Sengar (alias. @zengr ) en http://utkarshsengar.com/2011/01/manage-multiple-accounts-on-1-amazon-ec2-instance/ . He hecho sólo unos pequeños cambios.

Paso 1: inicie sesión de forma predeterminada por el usuario "ubuntu" :
$ ssh -i my_orig_key.pem [email protected]
Paso 2: crea un nuevo usuario, llamaremos a nuestro nuevo usuario "john" :
[ubuntu@ip-11-111-111-111 ~]$ sudo adduser john
Establecer la contraseña para "john" por:
[ubuntu@ip-11-111-111-111 ~]$ sudo su - [root@ip-11-111-111-111 ubuntu]$ passwd john
Agregue "john" a la lista de sudoer por:
[root@ip-11-111-111-111 ubuntu]$ visudo
.. y agregue lo siguiente al final del archivo:
john ALL = (ALL) ALL
¡Bien! Hemos creado nuestro nuevo usuario, ahora necesita generar el archivo de clave que será necesario para iniciar sesión, como tenemos my_orin_key.pem en el Paso 1.
Ahora, salga y vuelva a Ubuntu, sin root.
[root@ip-11-111-111-111 ubuntu]$ exit [ubuntu@ip-11-111-111-111 ~]$
Paso 3: creando las claves públicas y privadas :
[ubuntu@ip-11-111-111-111 ~]$ su john
Ingrese la contraseña que creó para "john" en el Paso 2. Luego cree un par de claves. Recuerde que la frase de contraseña para el par de claves debe tener al menos 4 caracteres.
[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
En el paso anterior, john es el usuario que creamos y ubuntu es el grupo de usuarios predeterminado.
[john@ip-11-111-111-111 ~]$ sudo chown john:ubuntu .ssh/authorized_keys
Paso 4: ahora solo necesitas descargar la clave llamada "john" . Utilizo scp para descargar / cargar archivos desde EC2, aquí es cómo puede hacerlo.
Aún deberá copiar el archivo usando el usuario de ubuntu , ya que solo tiene la clave para ese nombre de usuario. Por lo tanto, deberá mover la llave a la carpeta ubuntu y cambiarla a 777.
[john@ip-11-111-111-111 ~]$ sudo cp john /home/ubuntu/ [john@ip-11-111-111-111 ~]$ sudo chmod 777 /home/ubuntu/john
Ahora venga al terminal de la máquina local, donde tiene el archivo my_orig_key.pem y haga esto:
$ cd ~/.ssh $ scp -i my_orig_key.pem [email protected]:/home/ubuntu/john john
El comando anterior copiará la clave "john" al directorio de trabajo actual en su máquina local. Una vez que haya copiado la clave a su máquina local, debe eliminar "/ home / ubuntu / john", ya que es una clave privada.
Ahora, uno de su máquina local chmod john a 600.
$ chmod 600 john
Paso 5: hora de probar tu llave :
$ ssh -i john [email protected]

Entonces, de esta manera, ¡puede configurar múltiples usuarios para usar una instancia de EC2!

En mi caso, utilicé esta documentación para asociar un par de claves con mi instancia de Elastic Beanstalk

Importante
Debe crear un par de claves de Amazon EC2 y configurar las instancias de Amazon EC2 aprovisionadas de Elastic Beanstalk para usar el par de claves de Amazon EC2 antes de poder acceder a sus instancias de Elastic Beanstalk provisionadas de Amazon EC2. Puede configurar sus pares de claves de Amazon EC2 utilizando la Consola de administración de AWS. Para obtener instrucciones sobre cómo crear un par de claves para Amazon EC2, consulte la Guía de introducción de Amazon Elastic Compute Cloud.

Configuración de instancias de servidor de Amazon EC2 con Elastic Beanstalk

En su máquina local, ejecute el comando:

ssh-keygen -t rsa -C "SomeAlias"

Después de que se ejecute ese comando, se generará un archivo que termina en * .pub. Copia el contenido de ese archivo.

En la máquina de Amazon, edite ~ / .ssh / authorized_keys y pegue el contenido del archivo * .pub (y elimine primero cualquier contenido existente).

Luego puede SSH usando el otro archivo que se generó desde el comando ssh-keygen (la clave privada).

Esto me sucedió antes (no tuve acceso a una instancia de EC2 que alguien más creó pero tuvo acceso a la consola web de AWS) y escribí la respuesta en el blog: http://readystate4.com/2013/04/09/aws-gaining-ssh-access-to-an-ec2-instance-you-lost-access-to/

Básicamente, puede desconectar la unidad EBS, adjuntarla a un EC2 al que tenga acceso. Agregue su clave de publicación SSH a ~ec2-user/.ssh/authorized_keys en esta unidad adjunta. Luego vuelva a colocarlo en la antigua instancia de EC2. Paso a paso en el enlace mediante Amazon AMI.

No hay necesidad de hacer instantáneas o crear una nueva instancia clonada.

No encontré una manera fácil de agregar un nuevo par de claves a través de la consola, pero puedes hacerlo manualmente.

Simplemente ssh en su caja EC2 con el par de claves existente. Luego edite las teclas ~ / .ssh / authorized_keys y agregue la nueva clave en una nueva línea. Salir y ssh a través de la nueva máquina. ¡Éxito!

No puede aplicar un par de llaves a una instancia en ejecución. Solo puede utilizar el nuevo par de llaves para iniciar una nueva instancia.

Para la recuperación, si se trata de una AMI de arranque EBS, puede detenerla y hacer una instantánea del volumen. Crea un nuevo volumen basado en él. Y podrá utilizarlo de nuevo para iniciar la instancia anterior, crear una nueva imagen o recuperar datos.

Aunque los datos en el almacenamiento efímero se perderán.

Debido a la popularidad de esta pregunta y respuesta, quería capturar la información en el enlace que Rodney publicó en su comentario.

El crédito es para Eric Hammond por esta información .

Corrección de archivos en el volumen de EBS raíz de una instancia de EC2

Puede examinar y editar archivos en el volumen de EBS raíz en una instancia de EC2 incluso si se encuentra en una situación desastrosa como:

Perdiste tu clave ssh o olvidaste tu contraseña
Cometiste un error al editar el archivo / etc / sudoers y ya no puedes obtener acceso de root con sudo para solucionarlo
Su instancia de ejecución prolongada está bloqueada por algún motivo, no se puede contactar y falla al iniciar correctamente
Necesita recuperar archivos de la instancia pero no puede acceder a ella

En una computadora física que está sentada en su escritorio, simplemente puede iniciar el sistema con un CD o una memoria USB, montar el disco duro, revisar y reparar los archivos, y luego reiniciar la computadora para volver al trabajo.

Sin embargo, una instancia remota de EC2 parece distante e inaccesible cuando se encuentra en una de estas situaciones. Afortunadamente, AWS nos brinda el poder y la flexibilidad para poder recuperar un sistema como este, siempre que estemos ejecutando instancias de arranque de EBS y no un almacén de instancias.

El enfoque en EC2 es algo similar a la solución física, pero vamos a mover y montar el "disco duro" defectuoso (volumen de EBS de la raíz) a una instancia diferente, repararlo y luego devolverlo.

En algunas situaciones, podría ser simplemente más fácil iniciar una nueva instancia de EC2 y deshacerse de la mala, pero si realmente desea reparar sus archivos, este es el enfoque que ha funcionado para muchos:

Preparar

Identifique la instancia original (A) y el volumen que contiene el volumen de EBS raíz roto con los archivos que desea ver y editar.

instance_a=i-XXXXXXXX volume=$(ec2-describe-instances $instance_a | egrep ''^BLOCKDEVICE./dev/sda1'' | cut -f3)

Identifique la segunda instancia de EC2 (B) que usará para arreglar los archivos en el volumen EBS original. Esta instancia debe ejecutarse en la misma zona de disponibilidad que la instancia A para que pueda tener el volumen EBS adjunto. Si aún no tiene una instancia en ejecución, inicie una temporal.

instance_b=i-YYYYYYYY

Detenga la instancia rota A (en espera de que se detenga por completo), separe el volumen de EBS raíz de la instancia (en espera de que se desconecte), luego adjunte el volumen a la instancia B en un dispositivo no utilizado.

ec2-stop-instances $instance_a ec2-detach-volume $volume ec2-attach-volume --instance $instance_b --device /dev/sdj $volume

ssh a la instancia B y monta el volumen para que puedas acceder a su sistema de archivos.

ssh ...instance b... sudo mkdir -p 000 /vol-a sudo mount /dev/sdj /vol-a

Arreglalo

En este punto, su sistema de archivos raíz completo de la instancia A está disponible para ver y editar en / vol-a en la instancia B. Por ejemplo, puede querer:

Coloque las claves ssh correctas en /vol-a/home/ubuntu/.ssh/authorized_keys
Editar y corregir / vol-a / etc / sudoers
Busque mensajes de error en / vol-a / var / log / syslog
Copie archivos importantes de / vol-a /…

Nota: Los uids en las dos instancias pueden no ser idénticos, así que tenga cuidado si está creando, editando o copiando archivos que pertenecen a usuarios no root. Por ejemplo, su usuario mysql en la instancia A puede tener el mismo UID que su usuario postfix en la instancia B, lo que podría causar problemas si chown archivos con un nombre y luego mueva el volumen a A.

Envolver

Una vez que haya terminado y esté satisfecho con los archivos en / vol-a, desmonte el sistema de archivos (aún en instancia-B):

sudo umount /vol-a sudo rmdir /vol-a

Ahora, de nuevo en su sistema con ec2-api-tools, continúe moviendo el volumen de EBS de regreso a su hogar en la instancia original A y vuelva a iniciar la instancia:

ec2-detach-volume $volume ec2-attach-volume --instance $instance_a --device /dev/sda1 $volume ec2-start-instances $instance_a

Con suerte, solucionó el problema, la instancia A aparece muy bien y puede lograr lo que originalmente se propuso. De lo contrario, es posible que deba continuar repitiendo estos pasos hasta que funcione.

Nota: Si tenía una dirección de Elastic IP asignada a la instancia A cuando la detuvo, deberá volver a asociarla después de volver a iniciarla.

¡Recuerda! Si su instancia B se inició temporalmente solo por este proceso, no olvide finalizarla ahora.

Solo puede agregar una nueva clave a la instancia con el siguiente comando:

ssh-copy-id -i ~/.ssh/id_rsa.pub domain_alias

Puede configurar domain_alias en ~ / .ssh config

host domain_alias User ubuntu Hostname domain.com IdentityFile ~/.ssh/ec2.pem