2FA en SSH de Linux con pam_radius: aprobación en el teléfono para SSH y sudo

El mismo Notakey auth-proxy que ya protege su VPN y el acceso de administración a MikroTik puede proteger también los inicios de sesión en Linux. La pila PAM de Linux incluye un módulo RADIUS estándar: apúntelo al proxy y SSH, sudo y su exigirán una aprobación en el teléfono además de la contraseña.

sshd / sudo ──PAM──▶ pam_radius ──RADIUS──▶ Notakey auth-proxy ──▶ your RADIUS server
                                                    │
                                                    └──▶ push ──▶ user's phone

Esta guía está pensada para Debian/Ubuntu (libpam-radius-auth); en las distribuciones de la familia RHEL el módulo se empaqueta como pam_radius (EPEL) y los archivos de PAM residen bajo la misma estructura /etc/pam.d/.

Requisitos

Un auth-proxy en funcionamiento delante de un servidor RADIUS, configurado exactamente como en los pasos 1 a 3 de la guía de VPN.
El mismo nombre de usuario en el servidor RADIUS de destino, en el servicio de Notakey (con un teléfono registrado) y como cuenta en la máquina Linux. PAM solo autentica: el usuario sigue necesitando una cuenta local (o de directorio) en la que iniciar sesión.
Que la máquina Linux pueda alcanzar el proxy por UDP 1812. Entre ambos la contraseña viaja como PAP, así que mantenga este tráfico en una red de gestión, o ejecute el proxy en contenedor en el propio host.

Paso 0: prepare primero su salida de emergencia

Antes de tocar PAM, asegúrese de que funciona un inicio de sesión puramente local: dele a root (o a un administrador de emergencia dedicado) una contraseña local robusta y verifíquela en la consola. La configuración de más abajo siempre recurre a las contraseñas locales como respaldo, de modo que esta cuenta es su vía de acceso si alguna vez fallan el proxy, el servidor RADIUS o la red. Hágalo primero, no después de que algo se rompa.

Paso 1: instale el módulo

sudo apt-get install libpam-radius-auth

Paso 2: apúntelo al proxy

Edite /etc/pam_radius_auth.conf y añada una línea con la dirección del proxy, el secreto compartido (que empareja con el vpn_secret_in del proxy) y el tiempo de espera en segundos:

# server[:port]    shared_secret            timeout (s)
10.0.1.20          secret_to_radius_server  60

Después restrinja los permisos del archivo, que contiene el secreto:

sudo chmod 0600 /etc/pam_radius_auth.conf

El tiempo de espera es la misma trampa que en el resto de esta serie. El valor por defecto del módulo es de 3 segundos: suficiente para comprobar una contraseña, inútil para una aprobación humana. Ajústelo como mínimo al vpn_message_ttl del proxy (30 s); 60 deja un margen cómodo.

Paso 3: actívelo en PAM

Para cada punto de entrada que quiera proteger, añada una línea justo encima de la línea @include common-auth. Para SSH:

sudo nano /etc/pam.d/sshd

auth sufficient pam_radius_auth.so
@include common-auth

sufficient significa: si RADIUS responde Access-Accept —contraseña verificada en el destino y push aprobado—, el inicio de sesión tiene éxito de inmediato. Si no, PAM pasa a la comprobación normal de la contraseña local que figura debajo.

Añada la misma línea a cualquiera de estos archivos, según le convenga:

/etc/pam.d/login: inicios de sesión en consola
/etc/pam.d/sudo: cada sudo consulta al teléfono (potente, pero insistente; la caché de credenciales de sudo lo hace llevadero)
/etc/pam.d/su: cambio de usuario

Por último, edite /etc/pam.d/common-auth y añada try_first_pass a la línea pam_unix.so existente:

auth    [success=1 default=ignore]      pam_unix.so nullok_secure try_first_pass

(Las demás opciones de esa línea varían según la versión; lo único que se añade es try_first_pass.) Sin él, un usuario que recurra a la autenticación local verá cómo se le pide la contraseña una segunda vez; con él, la contraseña ya introducida se reutiliza de forma silenciosa.

Paso 4: compruebe que sshd usa PAM de verdad

En /etc/ssh/sshd_config, la autenticación basada en PAM necesita:

UsePAM yes
KbdInteractiveAuthentication yes

(ambos son los valores por defecto en Debian/Ubuntu). Conviene saber una cosa: los inicios de sesión SSH con clave pública se saltan por completo la fase de autenticación de PAM, por lo que un acceso basado en clave no dispara ninguna push. Si quiere clave más push, configure AuthenticationMethods publickey,keyboard-interactive, pero pruebe esa variante por separado antes de desplegarla.

Paso 5: cree usuarios solo con push

Aquí está el truco que deja la configuración limpia: cree usuarios sin contraseña local.

sudo useradd -m -G sudo john

Sin passwd después: la contraseña local de la cuenta queda bloqueada. Ese usuario tiene ahora exactamente una vía de acceso: RADIUS a través del proxy, es decir, contraseña y aprobación en el teléfono. No hay nada local que someter a fuerza bruta. Su administrador de emergencia del paso 0 sigue siendo la única cuenta con una contraseña puramente local.

Pruébelo, con cuidado

Mantenga abierta su sesión actual y conéctese por SSH desde un segundo terminal con un nombre de usuario de RADIUS:

La petición de contraseña se comporta como siempre; tras introducirla, la sesión se queda a la espera: es el proxy manteniendo abierto el intercambio.
La push llega al teléfono. Apruebe → shell. Rechace o ignore → el inicio de sesión falla al agotarse el tiempo de espera.
Confirme que la cuenta de emergencia sigue entrando con su contraseña local.

Cierre su sesión original solo después de que ambas comprobaciones pasen.

Resolución de problemas

El inicio de sesión falla al instante, sin push: el tiempo de espera en /etc/pam_radius_auth.conf sigue en su valor por defecto de 3 segundos, o el secreto no coincide con el vpn_secret_in del proxy.
No hay push, pero sí espera: no coincide el nombre de usuario entre RADIUS y el servicio de Notakey, o el teléfono no está registrado en esta aplicación.
Pide la contraseña dos veces: falta try_first_pass en la línea pam_unix de common-auth.
Los inicios de sesión SSH con clave no reciben push: es lo esperado; la autenticación con clave pública se salta la fase de autenticación de PAM (véase el paso 4).

Dónde encaja esto

Un solo proxy, un solo servidor RADIUS, y ahora la VPN, el plano de administración del router y todo su parque Linux exigen una aprobación en el teléfono. Cualquier cosa que hable RADIUS o PAM puede sumarse a la misma configuración.

Guías relacionadas

2FA para VPN con RADIUS: la configuración completa del auth-proxy: la configuración del proxy sobre la que se apoya esta guía
2FA en el acceso de administración a MikroTik: el mismo patrón para el propio inicio de sesión WinBox/SSH del router