Conectarse por primera vez a un servidor en la nube puede parecer sencillo, pero un detalle mal configurado basta para que la conexión nunca se establezca. Aquí se recorre paso a paso el proceso de conexión SSH a una instancia EC2 en AWS, desde la preparación de la llave hasta la resolución de un problema real de conectividad causado por el security group.

¿Cómo preparar la llave SSH para conectarte al servidor EC2?

Antes de lanzar cualquier comando de conexión, es necesario ubicar y dar permisos a la llave que se descargó al crear el key pair en el laboratorio anterior. El flujo es el siguiente:

• Abrir una terminal (compatible con Mac, Linux o Windows con terminal SSH instalada).
• Ejecutar pwd para verificar en qué directorio te encuentras [0:55].
• Navegar con cd hasta la carpeta donde se descargó la llave, típicamente la carpeta de descargas [1:14].
• Listar los archivos con ls para confirmar que la llave existe, en este caso un archivo llamado mi primera llave.pem [1:26].
• Asignar los permisos correctos con el comando chmod 400 mi_primera_llave.pem [1:50].

El comando chmod 400 restringe los permisos del archivo para que solo el propietario pueda leerlo. Sin este paso, SSH rechazará la llave por considerarla demasiado expuesta.

¿Cómo se construye la cadena de conexión SSH?

Con la llave lista, el siguiente paso es armar el comando completo de conexión. Para ello se necesita la dirección IP pública de la instancia, que se copia desde la consola de EC2 en el campo Public IPv4 address [2:05].

La estructura del comando es:

bash ssh ec2-user@<IP_PUBLICA> -i mi_primera_llave.pem

• ssh: protocolo de conexión segura.
• ec2-user: usuario por defecto en las imágenes Amazon Linux. Este nombre no cambia si utilizas la AMI estándar de Amazon [2:22].
• @IP: la dirección IP pública del servidor.
• -i: bandera que indica la ruta de la llave privada.

Al ejecutar este comando por primera vez, la conexión no se establece. La terminal queda en espera sin respuesta, lo cual ya es un síntoma claro de problema de conectividad [3:05].

¿Por qué falla la conexión y cómo hacer troubleshooting con el security group?

La causa raíz del fallo está en el security group, que funciona como un firewall virtual del servidor en la nube. Al revisarlo desde la consola de AWS, en la pestaña Security de la instancia, se observa que las inbound rules (reglas de entrada) están vacías [3:38]. Esto significa que ningún tráfico tiene autorización para llegar al servidor.

¿Qué regla de entrada se debe agregar?

Para permitir la conexión SSH se añade una regla con estas características [4:08]:

• Type: SSH.
• Protocol: TCP (se asigna automáticamente).
• Port: 22 (puerto por defecto de SSH).
• Source: en lugar de seleccionar Anywhere —lo cual dejaría el puerto abierto a todo el mundo y es una mala práctica—, se elige My IP para que AWS detecte automáticamente tu dirección IP actual [4:30].
• Description: por buenas prácticas, se documenta a quién pertenece esa IP.

Después de guardar la regla con Save, el puerto 22 queda habilitado exclusivamente para la IP configurada.

¿Cómo confirmar que la conexión funciona?

Se repite el mismo comando SSH. Esta vez la terminal solicita confirmación de autenticidad del host; al responder yes, la conexión se establece exitosamente [5:08]. Una vez dentro del servidor se pueden ejecutar comandos como:

• clear para limpiar la pantalla.
• pwd para confirmar que estás en /home/ec2-user.
• ls para listar archivos.

Desde ese momento se tiene control total como administrador (root) del servidor en la nube [5:22].

El consejo más valioso de este ejercicio es claro: siempre que tengas un problema de conectividad hacia una instancia EC2, el primer lugar donde debes mirar es el security group. Comparte en los comentarios si lograste conectarte o si encontraste algún obstáculo diferente durante el proceso.