Deshabilita el inicio de sesión por SSH y usa certificados

Cuando la autenticación con claves funcione correctamente, el servidor ya no necesitará aceptar contraseñas a través de la red. Esto impide cualquier intento de adivinar contraseñas. En esta sección se desactivará de forma segura el inicio de sesión mediante contraseña y como usuario raíz. Finalmente, verás cómo los certificados SSH facilitan la gestión del acceso a múltiples servidores.

Requisitos previos

• El registro con claves funciona, ver [[SSH Level 2 - Claves en lugar de contraseñas|SSH Level 2]].
• Tu usuario tiene sudo, ver [[Instalación del servidor Nivel 4 - Preparar el servidor|Preparar el servidor]].
• La consola de Proxmox está abierta. Es la ruta alternativa si te quedas bloqueado fuera de SSH.

Desactive el inicio de sesión con contraseña y como superusuario (root)

El servicio SSH lee las configuraciones desde /etc/ssh/sshd_config y desde los archivos en la carpeta /etc/ssh/sshd_config.d/. Crea un archivo propio para que sea fácil ver qué has cambiado y deshacerlo:

sudo nano /etc/ssh/sshd_config.d/10-seguro.conf

Introduce:

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

PasswordAuthentication no desactiva la autenticación por contraseña habitual. KbdInteractiveAuthentication no también desactiva la autenticación interactiva con teclado, que en caso contrario podría aceptar contraseñas a través de PAM. PermitRootLogin no impide completamente el inicio de sesión como usuario raíz (root).

Para la mayoría de las configuraciones de SSH, se aplica el primer valor leído por el servicio. Por lo tanto, tu archivo no prevalece automáticamente sobre otros archivos: la ubicación de Include, configuraciones anteriores y cualquier bloque Match pueden influir en el resultado. Verifica los valores efectivos antes de aplicar el cambio.

Verifique las configuraciones antes de cargarlas:

sudo sshd -t

Si no se recibe ningún mensaje, la sintaxis es válida. A continuación, consulte los valores que produce la nueva configuración:

sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|kbdinteractiveauthentication) '

Las tres deben mostrar no. Si obtienes otros valores, examina /etc/ssh/sshd_config y los archivos que incluye antes de continuar. Con las reglas Match, también verificas la conexión actual mediante sudo sshd -T -C user=user,addr=CLIP-CLIENTE,host=NOMBRE_CLIENTE; reemplaza los valores de ejemplo con el usuario, la dirección del cliente y el nombre del cliente para el inicio de sesión que estás probando. Realiza el mismo control en las tres configuraciones.

Una vez que los valores sean correctos, aplicas el cambio:

sudo systemctl reload ssh

No cierres la ventana en la que has iniciado sesión. Abre una nueva ventana de terminal y prueba:

ssh debian-vm                 # debe funcionar
ssh root@SERVER-IP            # debe ser rechazado
ssh -o PubkeyAuthentication=no user@SERVER-IP   # debe ser rechazado, sin solicitud de contraseña

La contraseña del usuario aún se necesita para sudo. Se escribe en el servidor, no a través de la red.

Aprofundamiento: Certificados SSH

Con diez servidores y cinco administradores, cada clave debe estar presente en cada servidor. Esto resulta en cincuenta entradas en authorized_keys, y cuando alguien se va, la clave debe eliminarse de todas partes.

Con los certificados, un emisor de certificados (CA) firma tu clave. Los servidores confían en el CA, no en cada individualmente. El certificado también contiene:

• principales: los nombres para los que aplica el certificado, por ejemplo admin
• plazo de validez: cuándo deja de funcionar el certificado

Configuración del servidor

Necesitas la clave pública de la entidad certificadora (CA) de quien opera la CA (por ejemplo, el profesor). Colócala en el servidor:

sudo nano /etc/ssh/lab_user_ca.pub

Determina qué principios pueden iniciar sesión como el usuario user:

sudo mkdir -p /etc/ssh/auth_principals
echo admin | sudo tee /etc/ssh/auth_principals/user

Informa al servicio SSH sobre la CA:

sudo nano /etc/ssh/sshd_config.d/10-lab-ca.conf

TrustedUserCAKeys /etc/ssh/lab_user_ca.pub
AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u

%u se reemplaza con el nombre de usuario en sesión. Verifique y cargue los cambios con sudo sshd -t y sudo systemctl reload ssh.

Iniciar sesión con el certificado

El certificado se encuentra junto a la clave privada y termina en -cert.pub. Consulte su contenido:

ssh-keygen -L -f ~/.ssh/id_ed25519-cert.pub

Busca los campos Principales, Válido y CA de firma. Inserta el certificado en ~/.ssh/config:

Host debian-vm
    HostName SERVER-IP
    User user
    IdentityFile ~/.ssh/id_ed25519
    CertificateFile ~/.ssh/id_ed25519-cert.pub

Ahora inicia sesión con ssh debian-vm sin que tu clave esté en authorized_keys del servidor.

Cómo firma la CA (para quien opera la CA)

ssh-keygen -t ed25519 -f lab_user_ca                  # crea la clave de una vez y guárdala en un lugar seguro
ssh-keygen -s lab_user_ca -I elev@skolen -n admin -V +52w id_ed25519.pub

-n son principals, -V es la fecha de vencimiento y -I es un ID que se muestra en los registros del servidor. La clave privada de la CA otorga acceso a todos los servidores que confían en ella, por lo tanto, nunca debe almacenarse en un servidor ni compartirse.

Si algo sale mal

1. Estás bloqueado fuera de la sesión: Inicia sesión en la consola de Proxmox, elimina el archivo que creaste en /etc/ssh/sshd_config.d/ y ejecuta sudo systemctl reload ssh.
2. sshd -t devuelve un mensaje de error: El mensaje muestra el nombre del archivo y el número de línea. Corrige el error ortográfico antes de cargarlo.
3. El certificado no es aceptado: Verifica que el principal del certificado (ssh-keygen -L) esté presente en /etc/ssh/auth_principals/user y que el certificado no haya caducado. En el servidor, sudo journalctl -u ssh -n 20 mostrará por qué se denegó el inicio de sesión.

Conceptos importantes

Controles

• ssh root@SERVER-IP se rechaza.
• El inicio de sesión con contraseña a través de SSH se rechaza.
• Puedes explicar por qué probaste en una nueva ventana antes de cerrar la antigua.
• Ampliación: puedes explicar por qué un CA es más sencillo que authorized_keys en muchos servidores.

Fuente: OpenSSH – sshd_config.