🛡️ Incidente: Rechazo de Conexión por Permisos Inseguros (SSH)
Descripción del Problema
Al intentar realizar el primer ansible -m ping desde el Control Node (WSL2) hacia el Managed Node (Vagrant VM), la tarea falló con el siguiente error crítico:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ WARNING: UNPROTECTED PRIVATE KEY FILE! @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@Permissions 0777 for 'private_key' are too open. This private key will be ignored.
Análisis de Causa Raíz (RCA)
-
Mecanismo de Seguridad de SSH: El cliente OpenSSH está diseñado para ignorar llaves privadas que sean legibles por otros usuarios (permisos de grupo o globales). Esto evita que, en un sistema multiusuario, un atacante local pueda exfiltrar la identidad de otro usuario.
-
Interoperabilidad WSL2/NTFS: El archivo de identidad se encontraba originalmente en
/mnt/c/(sistema de archivos Windows NTFS). Por defecto, WSL2 monta estos discos usando el driverDrvFs, asignando permisos0777(rwxrwxrwx) a todos los archivos para asegurar la compatibilidad, lo cual incumple los requisitos de seguridad de SSH.
Resolución Aplicada
Siguiendo el Principio de Menor Privilegio, se optó por migrar el secreto al sistema de archivos nativo de Linux para tener un control granular sobre los metadatos de seguridad:
- Migración de Datos: Se movió la llave privada del mount de Windows al volumen
ext4del usuario en WSL2.
cp /mnt/c/Users/trxpu/.../private_key ~/.ssh/id_vagrant_portfolio- Hardening de Permisos: Se aplicó una máscara de bits restrictiva.
chmod 600 ~/.ssh/id_vagrant_portfolio6(propietario): Lectura y escritura.0(grupo): Sin acceso.0(otros): Sin acceso.
Validación de Seguridad
Tras la corrección, el comando ansible webservers -m ping devolvió un estado de SUCCESS, confirmando que el motor de Ansible pudo cargar el secreto una vez que este cumplió con los estándares de integridad y confidencialidad exigidos.
