Administrando EC2 sin abrir el puerto 22: AWS Systems Manager Session Manager
Aprende a administrar instancias Amazon EC2 sin habilitar SSH ni exponer el puerto 22 a Internet. Implementaremos AWS Systems Manager Session Manager paso a paso, configurando IAM, conectividad y acceso mediante consola y AWS CLI, con recomendaciones de seguridad y auditoría.
Administrando EC2 sin abrir el puerto 22: AWS Systems Manager Session Manager
Introducción
Cuando comenzamos a trabajar con instancias Amazon EC2 basadas en Linux, una de las primeras tareas suele ser configurar el acceso remoto mediante SSH.
Normalmente generamos un par de llaves, habilitamos el puerto 22 en un Security Group y utilizamos un cliente SSH para conectarnos al servidor.
Este procedimiento es conocido y ampliamente utilizado. Sin embargo, cuando administramos múltiples instancias, cuentas y ambientes, aparecen nuevas necesidades.
¿Cómo administramos las llaves SSH de nuestros equipos?
¿Cómo controlamos quién puede conectarse a una instancia?
¿Cómo evitamos exponer innecesariamente servicios administrativos a Internet?
¿Podemos acceder a una EC2 que no tenga IP pública?
La respuesta a esta última pregunta es sí.
Con AWS Systems Manager Session Manager, podemos establecer sesiones administrativas en instancias EC2 sin abrir puertos de entrada, distribuir llaves SSH ni implementar un servidor bastión.
En este artículo construiremos un laboratorio paso a paso para entender cómo funciona.
1. ¿Qué es AWS Systems Manager Session Manager?
Session Manager es una capacidad de AWS Systems Manager que permite establecer sesiones interactivas con instancias EC2 y otros nodos administrados compatibles.
A diferencia del acceso SSH tradicional, Session Manager utiliza un agente instalado en el servidor, permisos IAM y conexiones seguras con los servicios de AWS.
Entre sus principales características encontramos:
- Acceso remoto mediante la consola de AWS.
- Acceso desde AWS CLI.
- Autorización mediante políticas IAM.
- Administración sin abrir el puerto 22.
- Posibilidad de trabajar con instancias sin IP pública.
- Integración con CloudTrail y opciones de registro de sesiones.
Es importante entender que no abrir el puerto 22 no significa eliminar todos los riesgos de seguridad. La protección depende también de las identidades autorizadas, los permisos asignados y la configuración de la instancia.
2. ¿Cómo funciona la conexión?
El flujo es relativamente sencillo:
- Un ingeniero inicia una sesión desde AWS Console o AWS CLI.
- AWS valida que su identidad tenga los permisos necesarios.
- Session Manager coordina la conexión con el SSM Agent de la instancia.
- Se establece la sesión mediante conexiones salientes cifradas.
- El ingeniero obtiene una terminal para realizar operaciones autorizadas.
La instancia no necesita recibir una conexión SSH entrante desde el equipo del administrador.
Esto permite reducir la superficie de exposición de la infraestructura.
3. Arquitectura del laboratorio
Para este ejemplo utilizaremos:
| Recurso | Configuración |
|---|---|
| Amazon EC2 | Amazon Linux 2023 |
| Región | us-east-1 |
| Instancia | t3.micro, o tipo compatible disponible |
| Red | Subred pública con salida a Internet |
| Security Group | Sin reglas de entrada |
| IAM Role | Rol EC2 con AmazonSSMManagedInstanceCore |
| Administración | AWS Systems Manager Session Manager |
Usaremos una subred pública por simplicidad. La instancia tendrá una IP pública y una ruta de salida por Internet Gateway, pero no permitiremos conexiones entrantes.
Aunque la instancia tenga una dirección pública, no significa que debamos publicar puertos administrativos.
Más adelante veremos cómo adaptar el laboratorio para una instancia privada.
4. Crear el rol IAM para la instancia
Antes de crear nuestra EC2, necesitamos permitir que SSM Agent se comunique con AWS Systems Manager.
Para ello crearemos un IAM Role.
Paso 1. Abrir IAM
Desde AWS Console:
- Accedemos a IAM.
- Seleccionamos Roles.
- Elegimos Create role.
- Seleccionamos AWS service como entidad de confianza.
- Elegimos EC2 como caso de uso.
Paso 2. Asignar permisos
Buscamos la política administrada:
AmazonSSMManagedInstanceCoreEsta política proporciona los permisos básicos necesarios para que un nodo administrado se comunique con Systems Manager.
Es importante distinguir dos tipos de permisos:
- Rol de la EC2: permite que SSM Agent se comunique con AWS.
- Permisos del ingeniero: permiten iniciar o administrar las sesiones.
La política de la instancia no sustituye los permisos IAM de quien desea conectarse.
Paso 3. Crear el rol
Utilizaremos el siguiente nombre:
role-ec2-ssm-pocAWS generará o utilizará un instance profile asociado al rol para que EC2 pueda obtener credenciales temporales.
5. Crear un Security Group sin acceso SSH
Ahora vamos a configurar la red de nuestra instancia.
Desde EC2:
- Seleccionamos Security Groups.
- Creamos un nuevo grupo.
- Lo asociamos a la VPC que utilizaremos.
- Eliminamos las reglas de entrada.
- Configuramos las reglas de salida necesarias.
Para este laboratorio, el Security Group tendrá:
Inbound Rules
Ninguna regla.
Outbound Rules
Permitiremos HTTPS por el puerto TCP 443 hacia los destinos necesarios.
Como simplificación, podemos utilizar una regla de salida TCP 443 hacia
0.0.0.0/0. Esta configuración no restringe la salida únicamente a AWS; en producción conviene aplicar una política de salida más específica.El objetivo es demostrar que no necesitamos abrir los puertos 22 ni 3389 para administrar el servidor mediante Session Manager.
6. Lanzar nuestra instancia EC2
Desde AWS Console accedemos a EC2 y seleccionamos Launch instance.
Configuraremos:
Nombre
ec2-ssm-poc-01AMI
Amazon Linux 2023.
Instance type
t3.micro, sujeto a disponibilidad y costos de la región.Key pair
Seleccionamos la opción para continuar sin un par de llaves.
Network settings
- VPC con conectividad a Internet.
- Subred pública.
- Asignación automática de IP pública habilitada.
- Security Group creado anteriormente.
Advanced details
En IAM instance profile seleccionamos el rol:
role-ec2-ssm-pocPara utilizar Session Manager necesitamos una AMI compatible y SSM Agent instalado y funcionando. Amazon Linux 2023 es una opción conveniente para este laboratorio, ya que las AMI oficiales habituales incluyen el agente.
Una vez iniciada la instancia, verificamos que se encuentre en estado
Running.7. Verificar que la instancia esté administrada por Systems Manager
Antes de conectarnos, revisaremos si Systems Manager reconoce nuestra instancia.
Desde la consola podemos acceder a:
AWS Systems Manager → Fleet Manager / Managed nodes
La navegación exacta puede variar según la versión de la consola.
Buscamos nuestra instancia EC2 y verificamos su estado.
También podemos consultar los nodos mediante AWS CLI:
1
2
3
4
aws ssm describe-instance-information \
--region us-east-1 \
--query 'InstanceInformationList[].{InstanceId:InstanceId,Status:PingStatus,Platform:PlatformName}' \
--output tableSi aparece con estado
Online, significa que el agente se está comunicando correctamente con Systems Manager.Si todavía no aparece, debemos revisar el rol IAM, la conectividad de red y el estado del agente.
8. Conectarnos sin SSH desde AWS Console
Con la instancia correctamente registrada:
- Abrimos Amazon EC2.
- Seleccionamos nuestra instancia.
- Elegimos Connect.
- Abrimos la pestaña Session Manager.
- Seleccionamos Connect.
Si nuestra identidad tiene los permisos necesarios, AWS abrirá una terminal interactiva.
Desde esta terminal podemos ejecutar:
1
whoami1
hostname1
cat /etc/os-release1
uptimeDe esta forma habremos accedido a una instancia EC2 sin configurar una llave SSH ni abrir el puerto 22.
En muchas configuraciones de Linux, la sesión utiliza inicialmente el usuario
ssm-user, que puede tener privilegios administrativos. Por esta razón es importante controlar estrictamente quién puede iniciar sesiones.9. Conectarnos utilizando AWS CLI
También podemos acceder desde nuestra computadora mediante AWS CLI.
Para este ejemplo necesitamos AWS CLI configurado, el Session Manager plugin instalado y permisos IAM suficientes.
Primero verificamos la identidad que estamos utilizando:
1
aws sts get-caller-identityDespués iniciamos una sesión, reemplazando el identificador de la instancia:
1
2
3
aws ssm start-session \
--target i-0123456789abcdef0 \
--region us-east-1Si la conexión se establece correctamente, tendremos una terminal interactiva.
Para finalizar ejecutamos:
1
exitEste método resulta especialmente útil cuando trabajamos desde una terminal local y necesitamos administrar múltiples servidores.
10. ¿Qué pasa si nuestra EC2 no tiene IP pública?
Hasta ahora utilizamos una instancia con salida a Internet.
Pero también podemos administrar instancias privadas mediante Session Manager.
En un entorno privado, podemos utilizar VPC Interface Endpoints, basados en AWS PrivateLink, para acceder a los servicios necesarios sin depender de una ruta pública hacia Internet.
Entre los endpoints relevantes se encuentran:
1
2
com.amazonaws.us-east-1.ssm
com.amazonaws.us-east-1.ssmmessagesEl endpoint
ec2messages puede ser necesario en determinadas regiones y configuraciones heredadas. La necesidad exacta depende de la región, el agente y las características utilizadas.También debemos considerar el DNS privado, los Security Groups de los endpoints y permisos apropiados.
Si la instancia necesita otros servicios, como CloudWatch Logs o Amazon S3, podrían requerirse endpoints adicionales.
Esta arquitectura resulta interesante para ambientes donde buscamos que los servidores no tengan direcciones IP públicas.
No obstante, los VPC Interface Endpoints tienen costos asociados y deben evaluarse según los requisitos del entorno.
11. Auditoría y registro de sesiones
Desde una perspectiva de seguridad y operaciones, no basta con permitir el acceso remoto.
También necesitamos establecer controles sobre quién puede acceder y registrar las acciones relevantes.
Session Manager puede integrarse con:
AWS CloudTrail
Registra eventos relacionados con las API de Session Manager, como el inicio y finalización de sesiones.
Amazon CloudWatch Logs
Permite almacenar la salida de sesiones interactivas estándar cuando configuramos el registro de sesiones.
Amazon S3
Puede utilizarse como destino de almacenamiento de registros.
Debemos distinguir entre registrar eventos de conexión y registrar el contenido de una sesión.
CloudTrail no equivale a una grabación completa de los comandos ejecutados.
Además, el registro del contenido no está disponible para sesiones SSH o de port forwarding canalizadas mediante Session Manager.
La configuración de auditoría debe responder a los requisitos de seguridad de nuestra organización.
12. Buenas prácticas desde DevOps y SRE
1. Evitar SSH público cuando no sea necesario
No debemos abrir el puerto 22 solamente porque estamos utilizando Linux.
Antes de hacerlo, conviene evaluar mecanismos de acceso administrado como Session Manager.
2. Aplicar mínimo privilegio
No todos los usuarios necesitan iniciar sesiones en todas las instancias.
Podemos utilizar IAM para limitar los recursos y acciones permitidas.
3. Priorizar credenciales temporales
Es recomendable utilizar identidades federadas y roles en lugar de distribuir credenciales de larga duración.
4. Mantener SSM Agent actualizado
Las versiones del agente incorporan mejoras y compatibilidad con nuevas funcionalidades.
5. Habilitar auditoría cuando corresponda
Para ambientes empresariales, es recomendable definir controles de monitoreo y retención de registros.
6. Considerar conectividad privada
Cuando la arquitectura lo requiera, podemos utilizar VPC Endpoints para mantener los servidores sin IP pública.
7. Revisar los permisos dentro del sistema operativo
Una sesión autorizada por IAM puede proporcionar una cuenta con privilegios elevados dentro del servidor.
Es importante controlar el usuario del sistema operativo utilizado y sus permisos.
13. Resolución de problemas comunes
La instancia no aparece en Systems Manager
Revisar:
- IAM Role asociado.
- SSM Agent instalado y activo.
- Acceso saliente HTTPS.
- Rutas de la subred.
- DNS y conectividad a endpoints.
- Región seleccionada.
En Amazon Linux 2023 podemos revisar el servicio del agente:
1
sudo systemctl status amazon-ssm-agentEn instalaciones donde el agente utiliza Snap, el nombre del servicio puede ser diferente.
AccessDenied al iniciar una sesión
El problema puede estar en la identidad del usuario que solicita la conexión.
Debemos revisar sus permisos IAM y cualquier control organizacional que limite la operación.
TargetNotConnected
Puede indicar que la instancia no tiene conectividad activa con Systems Manager o que el agente no está conectado correctamente.
Revisar agente, endpoints, rutas, DNS y políticas IAM suele ser el primer paso.
Conclusión
Administrar servidores no significa necesariamente abrir SSH o distribuir llaves privadas a todos los integrantes de un equipo.
Con AWS Systems Manager Session Manager podemos establecer un mecanismo de acceso remoto basado en identidades IAM, conectividad saliente y agentes administrados.
Este enfoque permite reducir la exposición de puertos administrativos y simplificar determinados procesos operativos.
Sin embargo, su adopción debe acompañarse de políticas de acceso, monitoreo, mantenimiento del agente y controles adecuados sobre los privilegios del sistema operativo.
Desde una perspectiva DevOps y SRE, el objetivo no debería ser solamente encontrar una manera de conectarnos a los servidores.
Deberíamos preguntarnos cómo podemos administrarlos de forma segura, consistente y auditable.
¿En tu organización todavía utilizan SSH para administrar instancias EC2 o ya trabajan con AWS Systems Manager Session Manager?
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article