Tengo problemas para ingresar a mi instancia AWS EC2
Aunque lo use de manera especifica por un problema con el SSH, la misma mecánica sirve para recuperar datos e información de un sistema que se corrompe, se desdoraba en capacidad de disco o cualquier otro tópico que impida que la instancia se inicie de forma adecuada.
El problema es que la opción conectar también hace uso de SSH por lo tanto es una opción que no me sirvió, intente por consola serial pero tiene el problema que solo funciona para aquellas instancias que tiene plan de soporte Premiun o que están baja la modalidad EBS-NITRO, lo que cual para la instancias de uso como como como las T2,T2,T5 no funciona, total por ese lado nada que hacer.
También intente son S3 pero el mismo problema tienes que ingresar primero a la instancia con SSH y hacer una copia en un S3 BUCKET , tampoco me sirvió
Intente luego AWS-CLI , pero tiene el problema que se puede descargar cualquier archivo pero solo si previamente está en S3 o sea el mismo cuento.
También intente con opción AWS-BACUP pero lo que hace es crear una imagen de la instancia y en este caso hizo una imagen pero con el mismo problema.
Ya me estaba desesperando un poco y como tampoco tengo un plan PREMIUN , no me deja reportar el error, o sea el problema del huevo y la gallina , como no puedo usar la instancia no puedo seleccionar plan PREMIUM y como no tengo plan PREMIUN no puedo reportar el problema.
Así que como no me queda otra me comunique con el departamento de ventas como lograba destrabar este inconveniente, afortunadamente dí con una funcionaria super diligente de nombre ANICITA, que Dios la bendiga, que aunque no era su departamento pues es de ventas, busco por todas partes y logro conseguir el documento que transcribo aquí. (mas abajo está en inglés)
En resumidas cuentas el proceso es sencillo cuando se entiende:
1. Hay que detener la instancia que tiene el problema
2. Luego desvincular el volumen donde esta la información de esta instancia mediante la opción VOLUMEN -> desvincular
Si me lo permiten es como si apago el computador y saco el disco duro, burdo pero se entiende.
3, Creo otra instancia nueva, ojo debe tener la misma zona de DISPONIBILIDAD del la instancia problema, esto me costo un poco porque no entendía a que se refería, pensé que era la zona de ubicación de la instancia en mi caso VIRGINIA, pero no podía que me reconociera que estaba en la misma zona de disponibilidad, lo que sucede es que la Zona si es virginia o sea us-east1 , pero la zona disponibilidad es lo que ellos llaman la subred que en mi caso era us-east-1_1c y cuando se crea instancia el sistema selecciona una que este disponible , pero en este caso es vital que tanto la nueva instancia que va servir para el rescate y la que tiene el problema estén ambas en la misma subred (zona de disponibilidad) así que cuando se crea esta nueva instancia donde se va corregir el problema donde pregunta subred, darle la misma que tiene la instancia que tiene el problema.
Esta información esta en la pestaña de la instancia denominada subred.
4, Ya creada la nueva instancia con la subred correcta, es simplemente ir de nueva a VOLUMENES y asociar el volumen que antes desvinculo a esta nueva instancia, es decir como si pasara el disco duro del computador con el problema a uno nuevo que va servir de paso mientas se corrige el problema.
5, Una vez asociado el volumen a la instancia los puedes montar (mount ver instructivo mas abajo ) como un disco duro normal y procedes hacer los cambios que necesita o sacar la información que se requiera.
6, En mi caso remplace los archivos que se habían dañando yendo a la carpeta donde monte el disco y emplazándolos por unos buenos. ( /etc/ssh/sshd-config )
7, Una vez hecho esto , hago lo mismo pero al contrario, detengo la instancia de rescate, desvinculo el volumen que le había asociado, voy de nuevo a VOLÚMENES y asocio el volumen a su instancia original , eso es todo.
Ojo hay que tener cuidado con algo y es el nombre del dispositivo de vinculación , cuando desvincula el dispositivo le coloca un nombre como por ejemplo /dev/sdf1 que es en general es el dispositivo de volúmenes disponibles pero cuando lo quiera volver a instalar en la instancia corregida, el dispositivo es /es algo como /dev/xvdf1 o algo similar, sino selecciona el dispositivo correcto cuando lance la instancia de nuevo le marca un error diciendo que la instancia no tiene volumen de inicio, en el primer caso no hay problema porque cunado se haga el mount le digo cual dispositivo quiero pero al volver al sistema original es el que la instancia ya tiene por defecto.
En resumen la descripción que que sigue funciona bien , solo hay que tener dos cosas a tener en cuenta , la zona de disponibilidad (subred) y el nombre correcto del dispositivo en cada caso.
I made changes to my EC2 instance's sshd_config file. Now I can't access my instance using SSH. How do I resolve this?
Last updated: 2021-08-16
I changed my Amazon Elastic Compute Cloud (Amazon EC2) instance's sshd_config file, and now I can't access my instance using SSH. How can troubleshoot and I resolve this?
Short description
Changing an instance's sshd_config file might cause a connection refused error when connecting through SSH.
To confirm that you can't access the instance due to a connection refused error, access the instance through SSH with verbose messaging on:
$ ssh -i "myawskey.pem" ec2-user@ec2-11-22-33-44.eu-west-1.compute.amazonaws.com -vvvThe preceding example uses myawskey.pem for the private key file, and ec2-user@ec2.11.22.33.44 as the user name. Substitute your key file and user name for the example's key file and user name. Make sure that you use the Region where your instance is located.
The following example output shows the connection refused error message:
OpenSSH_7.9p1, LibreSSL 2.7.3
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 48: Applying options for *
debug1: Connecting to ec2-11-22-33-44.eu-west-1.compute.amazonaws.com port 22.
ssh: connect to host ec2-11-22-33-44.eu-west-1.compute.amazonaws.com port 22: Connection refusedResolution
Note: If you're using a Nitro-based instance, then device names differ from the examples given in the following steps. For example, instead of /dev/xvda or /dev/sda1, the device name on a Nitro-based instance is /dev/nvme. For more information, see Device names on Linux instances.
Method 1: Use the EC2 Serial Console
If you enabled EC2 Serial Console for Linux, then you can use it to troubleshoot supported Nitro-based instance types. The serial console helps you troubleshoot boot issues, network configuration, and SSH configuration issues. The serial console connects to your instance without the need for a working network connection. You can access the serial console using the Amazon EC2 console or the AWS Command Line Interface (AWS CLI).
Before using the serial console, grant access to the console at the account level. Then create AWS Identity and Access Management (IAM) policies granting access to your IAM users. Also, every instance using the serial console must include at least one password-based user. If your instance is unreachable and you haven’t configured access to the serial console, follow the instructions in the following section, Method 2: Use a rescue instance. For information on configuring the EC2 Serial Console for Linux, see Configure access to the EC2 Serial Console.
Note: If you receive errors when running AWS CLI commands, make sure that you’re using the most recent version of the AWS CLI.
Method 2: Use a rescue instance
Warning: Before stopping and starting your instance, be sure you understand the following:
- If your instance is instance store-backed or has instance store volumes containing data, then the data is lost when you stop the instance. For more information, see Determine the root device type of your instance.
- If your instance is part of an Amazon EC2 Auto Scaling group, then stopping the instance might terminate the instance. Instances launched with Amazon EMR, AWS CloudFormation, or AWS Elastic Beanstalk might be part of an AWS Auto Scaling group. Instance termination in this scenario depends on the instance scale-in protection settings for your Auto Scaling group. If your instance is part of an Auto Scaling group, then temporarily remove the instance from the Auto Scaling group before starting the resolution steps.
- Stopping and starting the instance changes the public IP address of your instance. It's a best practice to use an Elastic IP address instead of a public IP address when routing external traffic to your instance. If you're using Route 53, then you might have to update the Route 53 DNS records when the public IP changes.
1. Launch a new EC2 instance in your virtual private cloud (VPC). Use the same Amazon Machine Image (AMI) in the same Availability Zone as the impaired instance. The new instance becomes your rescue instance.
2. Stop the impaired instance.
Note: If you use a store-backed instance or have instance store volumes containing data, then the data is lost when you stop the instance. For more information, see Determine the root device type of your instance.
3. Detach the Amazon Elastic Block Store (Amazon EBS) root volume (/dev/xvda or /dev/sda1) from your impaired instance.
4. Attach the EBS volume as a secondary device (/dev/sdf) to the rescue instance.
5. Connect to your rescue instance using SSH.
6. Run the lsblk command to view devices:
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda 202:0 0 8G 0 disk
└─xvda1 202:1 0 8G 0 part /
xvdf 202:80 0 8G 0 disk
└─xvdf1 202:81 0 8G 0 part7. Create a mount point directory (/rescue) for the new volume that you attached to the rescue instance in step 4:
$ sudo mkdir /mnt/rescue8. Mount the volume at the directory you created in step 7:
$ sudo mount -t xfs -o nouuid /dev/xvdf1 /mnt/rescue/To mount ext3 and ext4 file systems, run the following command:
$ sudo mount /dev/xvdf1 /mnt/rescueNote: The syntax of the preceding mount command might vary. For more information, run the man mount command.
9. Run the lsblk command again to verify the volume mounted the directory:
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda 202:0 0 8G 0 disk
└─xvda1 202:1 0 8G 0 part /
xvdf 202:80 0 8G 0 disk
└─xvdf1 202:81 0 8G 0 part /mnt/rescueCorrect or copy the sshd_config file
You can investigate the sshd_config file on your impaired instance and rollback your changes. Use the SSH verbose messaging output to guide you to the error location in the file.
$ sudo vi /mnt/rescue/etc/ssh/sshd_configOr, copy the sshd_config file from the rescue instance to your impaired instance using the following command. This command replaces the contents of the sshd_config file on your original instance.
$ sudo cp /etc/ssh/sshd_config /mnt/resscue/etc/ssh/sshd_configReattach the volume to the original instance and test the connection
Note: Complete the following steps if you used Method 2: Use a rescue instance.
1. Run the umount command to unmount the volume:
$ sudo umount /mnt/rescue/2. Detach the secondary volume from the rescue instance, and then attach the volume to the original instance as /dev/xvda (root volume).
4. Connect to the instance using SSH to verify that you can reach the instance.
Comentarios
Publicar un comentario