Asegurar SSH en CentOS 7 con autenticación de dos factores WiKID

Por qué añadir 2FA a SSH

SSH ofrece un canal seguro para administración remota, pero en auditorías regulatorias como PCI puede causar observaciones por limitaciones de autenticación. Problemas habituales:

• No hay control fino sobre quién usa claves públicas
• No hay enforcement de complejidad o expiración de frase de paso para claves
• No hay expiración nativa de claves públicas

Añadir autenticación de dos factores reduce el riesgo por credenciales comprometidas y facilita cumplimiento y auditoría gracias a desactivación centralizada y logging.

Requisitos previos

• Servidor CentOS 7 en producción o laboratorio con acceso root
• Servidor WiKID Strong Authentication disponible y accesible desde el servidor CentOS
• IPs de los gateways o servidores SSH que actuarán como clientes RADIUS
• Herramientas de compilación en CentOS: gcc, make, pam-devel
• Acceso a las interfaces de administración de WiKID

Importante: planificar ventanas de prueba para no bloquear accesos remotos sin una cuenta alternativa de recuperación

Añadir un dominio al servidor WiKID

En la consola de WiKID cree un nuevo dominio. El campo Domain Server Code debe ser la dirección IP externa de su servidor rellenada con ceros a la izquierda hasta 12 dígitos. Ejemplo:

• IP: 54.83.0.181
• Domain Server Code: 054083000181

Notas:

• El código de dominio se usa como identificador único del servidor en WiKID
• Mantenga a mano la IP y el código para posteriores pasos de configuración de clientes de red

Crear un cliente de red en WiKID

Después de guardar el dominio, vaya a la pestaña Network Client y seleccione Create New Network Client. Rellene:

• Nombre descriptivo del cliente
• IP del gateway o del servidor SSH en la red interna
• Protocolo: RADIUS
• Dominio: el dominio creado previamente

Al Añadir, en la siguiente pantalla introduzca el shared secret que usará RADIUS entre el servidor WiKID y el cliente.

Repita el proceso para cada servidor o gateway SSH que vaya a usar WiKID.

Configurar SSH en el servidor CentOS 7

A continuación configuraremos el servidor objetivo. En CentOS 7 instalaremos pam_radius para delegar la validación al servidor WiKID.

1. Descargar el tarball de código fuente

$ wget ftp://ftp.freeradius.org/pub/radius/pam_radius-1.3.17.tar.gz

2. Descomprimir

$ tar -xzvf pam_radius-1.3.17.tar.gz

3. Instalar dependencias

$ sudo yum install pam-devel

4. Compilar

Cambie al directorio creado por la descompresión y ejecute

$ make

Es posible que aparezcan advertencias. Si se crea el fichero compartido .so, la compilación fue satisfactoria.

5. Copiar la librería al directorio de módulos PAM según arquitectura

$ sudo cp pam_radius_auth.so /lib/security/

o en sistemas x86_64

$ sudo cp pam_radius_auth.so /usr/lib64/security/

6. Indicar a SSH que use RADIUS

Edite el fichero de configuración PAM para SSH, normalmente /etc/pam.d/sshd. Añada la siguiente línea como segunda entrada de autenticación para delegar a pam_radius

auth    sufficient    /lib/security/pam_radius_auth.so

Explicación:

• sufficient permite que si pam_radius responde con éxito la autenticación termine sin seguir otras reglas
• cambiar a required obligará a que sólo RADIUS sea válido; recomendable hacer esto sólo después de pruebas exhaustivas

Recomendación: deje la opción en sufficient mientras prueba para evitar perder acceso si hay un fallo remoto

7. Configurar el cliente RADIUS

Edite o cree el fichero /etc/pam_radius_auth.conf y añada la línea con IP o hostname del servidor WiKID y el shared secret configurado en el paso anterior

$ sudo vim /etc/pam_radius_auth.conf

Formato esperado de la línea ejemplo

192.0.2.10    sharedsecret    3

Donde el tercer campo es el número de reintentos o puerto según versión; consulte la documentación de pam_radius instalada si tiene dudas

8. Pruebas y logs

Ejecute en otra sesión

tail -f /var/log/secure

y pruebe un inicio SSH. Observe mensajes de éxito o fallo y depure según corresponda.

Notas sobre cuentas de usuario:

• No modificamos el esquema de cuentas local; los usuarios deben tener cuenta local o bien integre autenticación de cuentas con pam_ldap o pam_sss para usar AD/LDAP para autorización

Reforzamiento y opciones adicionales

• Forzar 2FA solo para root o para determinados grupos: cree un dominio WiKID distinto para su política su/root y modifique /etc/pam.d/su para apuntar a ese dominio
• Combinar autenticación por clave pública y RADIUS: puede requerir publickey y keyboard-interactive simultáneamente usando la opción AuthenticationMethods en OpenSSH
• Desactivar contraseñas locales y permitir solo autenticación por RADIUS cuando haya probado la configuración en todos los accesos administrativos

Alternativas y cuándo usar cada enfoque

• WiKID vía RADIUS: buena opción cuando ya existe infraestructura RADIUS o se necesita integración centralizada con tokens físicos o móviles
• Duo Security u otros SaaS: ofrecen integración más sencilla con portales de administración y móvil, a cambio de servicio externo
• Google Authenticator PAM: solución local y gratuita para tokens TOTP, útil en entornos sencillos sin RADIUS
• U2F/WebAuthn: ideal cuando se dispone de llaves físicas modernas y se quiere FIDO2, pero requiere adaptaciones

Elegir depende de requisitos de auditoría, presupuesto y política de gestión de tokens

Mini metodología de despliegue (pasos recomendados)

1. Preparar servidor WiKID y crear dominio de prueba
2. Crear un cliente RADIUS para un servidor lab
3. Compilar e instalar pam_radius en servidor de laboratorio
4. Probar con cuentas de prueba y supervisar /var/log/secure
5. Documentar shared secrets y políticas de token en vault seguro
6. Migrar por oleadas, monitorizar y recoger feedback
7. Forzar required cuando todas las rutas de acceso estén validadas

Lista de comprobación por roles

Administrador de sistemas

• Confirmar acceso de emergencia con consola o IPMI
• Compilar e instalar pam_radius en entorno de pruebas
• Documentar configuración en control de cambios

Auditor de seguridad

• Verificar que los eventos de autenticación quedan registrados centralmente
• Comprobar que existe mecanismo para desactivar tokens de usuarios

Responsable de identidad

• Revisar políticas de caducidad y reemisión de tokens
• Confirmar integraciones con LDAP/AD si corresponde

Criterios de aceptación y pruebas

• Un usuario sin token no puede iniciar sesión por SSH si el método final es required
• La revocación desde WiKID impide inmediatamente nuevos inicios
• Todos los intentos de autenticación quedan registrados en logs centrales
• Pruebas de recuperación: restablecimiento de tokens y acceso de emergencia validado

Resolución de problemas comunes

• Fallan inicios y /var/log/secure muestra errores de comunicación RADIUS: comprobar conectividad UDP al puerto RADIUS, firewall y shared secret
• Módulo pam_radius no encontrado: comprobar copia del .so en el directorio correcto según arquitectura
• Respuesta de RADIUS aceptada pero usuario no autorizado: verificar mapeo entre usuario local y usuario en WiKID o esquema de autorización LDAP

Seguridad, privacidad y cumplimiento

• Logging: mantenga registros centralizados y protegidos; defina retención conforme a requisitos de auditoría
• Protección de secretos: shared secrets RADIUS deben guardarse en vault seguro y rotarse según política
• Privacidad: si los tokens se asocian a identificadores personales, asegúrese de documentar el tratamiento y, si aplica, notificar según GDPR

Compatibilidad y migración

• pam_radius es ampliamente compatible con RHEL/CentOS y sus forks; versiones muy antiguas de OS pueden requerir ajustes
• Para migraciones a sistemas más recientes considere soluciones soportadas por el proveedor o módulos modernos para SSSD y FreeRADIUS

Mini diagrama de decisiones

flowchart TD
  A[¿Ya tiene RADIUS o WiKID?] -->|sí| B[Configurar cliente RADIUS en WiKID]
  A -->|no| C[Evaluar: instalar WiKID o usar alternativa]
  B --> D[Instalar pam_radius en servidor CentOS 7]
  D --> E[Provisionar usuario y token de prueba]
  E --> F[Probar SSH y logs]
  F --> G{Pruebas OK}
  G -->|sí| H[Plan de despliegue por oleadas]
  G -->|no| I[Depurar conectividad, secrets, PAM]

Ejemplo de flujo de rollback en caso de fallo en remoto

1. Si los administradores quedan bloqueados, acceder por consola de emergencia o KVM/IPMI
2. Restaurar copia de seguridad de /etc/pam.d/sshd o revertir la línea añadida
3. Reiniciar servicio sshd y validar accesos locales
4. Analizar logs y corregir configuración RADIUS antes de reintentar

Recursos y enlaces

• CentOS: http://www.centos.org
• PAM RADIUS: http://freeradius.org/pam_radius_auth/
• WiKID Two-factor authentication: https://www.wikidsystems.com

Resumen

• Integrar WiKID mediante RADIUS mejora la seguridad y facilita auditorías
• Pruebe primero en entorno controlado y deje sufficient antes de forzar required
• Documente shared secrets, procedimientos de recuperación y políticas de rotación

Importante: siempre mantenga un mecanismo de acceso de emergencia cuando realice cambios en la autenticación remota