Rocky Linux / Permitir SSH como root con autenticación por clave pública

Se puede permitir el inicio de sesión SSH de la cuenta root en Rocky Linux, pero es más seguro y fácil de auditar usar una cuenta de administrador normal junto con sudo. Si es absolutamente necesario el acceso directo de root, no habilite el inicio de sesión con contraseña y permita solo la autenticación por clave pública; luego aplíquelo tras revisar la configuración y realizar pruebas en una sesión aparte.

Revisión del método recomendado primero

Inicie sesión como usuario normal y ejecute solo los comandos necesarios con sudo; esto reduce la exposición directa de las credenciales root y permite registrar el historial de operaciones por usuario.

sudo useradd adminuser
sudo usermod -aG wheel adminuser

Después de crear la cuenta, registre la clave pública y verifique en una nueva sesión que sudo -v funciona. Debe probarlo antes de cerrar cualquier conexión SSH existente para evitar quedar bloqueado por un error de configuración.

La nueva cuenta no tendrá contraseña para sudo automáticamente; solo se ha preparado para inicio de sesión con clave pública. Si la política de wheel requiere su propia contraseña, prepare la autenticación con sudo passwd adminuser y verifique sudo -v en una nueva sesión conforme a la política. NOPASSWD no se permite ampliamente como solución para evitar esto. Si adminuser ya existe, no repita useradd; investigue el estado real de la cuenta.

Verificación de la configuración actual de SSH y login de root

Es más preciso verificar la configuración efectiva final combinando los archivos de inclusión y los valores predeterminados con sshd -T que solo observar una línea en el archivo de configuración.

sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|pubkeyauthentication) '
sudo grep -RinE '^[[:space:]]*(PermitRootLogin|PasswordAuthentication|PubkeyAuthentication)' \
  /etc/ssh/sshd_config /etc/ssh/sshd_config.d

Las configuraciones con condiciones Match pueden producir resultados diferentes según el usuario que se conecte y la dirección de origen. En entornos complejos, especifique la condición real con sshd -T -C para verificarla.

Preparación de la clave pública de root

Archivo de clave y configuración de permisos

Registre solo la clave pública de un administrador autorizado en /root/.ssh/authorized_keys. Sustituya toda la cadena entre comillas por una línea pública real con un algoritmo permitido por la política del sistema. Los campos BASE64_DE_LA_CLAVE_PUBLICA e IDENTIFICADOR_DEL_ADMINISTRADOR son marcadores, no una clave válida. Revise las claves existentes antes de añadirla y mantenga la privada en el cliente.

sudo install -d -m 700 -o root -g root /root/.ssh
echo 'ssh-ed25519 BASE64_DE_LA_CLAVE_PUBLICA IDENTIFICADOR_DEL_ADMINISTRADOR' | sudo tee -a /root/.ssh/authorized_keys
sudo chown root:root /root/.ssh/authorized_keys
sudo chmod 600 /root/.ssh/authorized_keys
sudo restorecon -Rv /root/.ssh

La clave privada no se debe subir al servidor. Al agregar una clave pública, asegúrese de que no se rompa la línea y de que no esté duplicada con claves ya registradas.

Restricciones de la propia clave pública

Si la clave es solo para automatización, puede limitar el origen de conexión y las funciones ejecutables con opciones from=, command=, restrict como authorized_keys. Sin embargo, restricciones incorrectas pueden interrumpir las tareas, así que pruébelas primero con otra clave.

Configuración válida que requiere autenticación de clave pública para root

Realice una copia de seguridad de toda la configuración y verifique la estructura Include·Match de la configuración principal. OpenSSH utiliza primero los valores leídos en muchos elementos, por lo que no se debe asumir que un nombre de archivo grande como 90 sobrescriba los valores existentes. A continuación se muestra un ejemplo de un bloque exclusivo para root al final de /etc/ssh/sshd_config, y si existe un Match para root existente, se modifica el bloque válido. No coloque Match inadvertidamente en archivos incluidos al principio para no cambiar la interpretación de la configuración global posterior.

Match User root
    PermitRootLogin prohibit-password
    PubkeyAuthentication yes
    AuthenticationMethods publickey

prohibit-password deshabilita para root la autenticación por contraseña y la interactiva de teclado; por sí solo no exige exclusivamente clave pública. Aquí AuthenticationMethods publickey la exige expresamente. No reemplace una política existente de autenticación multifactor por una sola clave.

sudo sshd -t
sudo sshd -T -C user=root,host=client.example.test,addr=192.0.2.10 | grep -E "^(permitrootlogin|pubkeyauthentication|passwordauthentication|authenticationmethods) "

Sustituya el host y la dirección por las condiciones reales. Si Match depende de la dirección o puerto local, añada los parámetros laddr o lport correspondientes en sshd -T -C. Compruebe root y el administrador habitual antes de recargar; después pruebe acceso permitido, acceso rechazado y sudo en sesiones nuevas manteniendo abierta la actual.

Verificación de sintaxis, aplicación y prueba en sesión separada

1. Mantenga abierta la sesión del administrador actual.
2. Verifique la sintaxis con sshd -t. No debe haber salida y el estado de salida debe ser 0.
3. Recargue el servicio SSH.
4. Pruebe el inicio de sesión de root con clave pública en un nuevo terminal.
5. Se rechaza el inicio de sesión con contraseña y se verifica si la cuenta de administrador existente está normal.

sudo sshd -t
sudo systemctl reload sshd
sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|pubkeyauthentication) '

Si la comprobación de sintaxis falla, no recargue el servicio y corrija el archivo y la línea señalados por el error. Aunque reload es más ventajoso para mantener la conexión existente que reiniciar, es más seguro no cerrar la sesión actual hasta que se complete la prueba de nueva conexión.

Métodos para reducir aún más el alcance de la conexión

Permitir solo la red de administración en el firewall

No exponga el puerto SSH a toda la Internet y permita solo la dirección de origen de la VPN o de la red de administración. Las direcciones a continuación son ejemplos para documento, por lo que deben reemplazarse con la red de administración real.

sudo firewall-cmd --get-active-zones
sudo firewall-cmd --zone=public --add-rich-rule='rule family="ipv4" source address="192.0.2.0/24" service name="ssh" accept'

192.0.2.0/24 es una red reservada para documentación: use el origen real que ve el servidor, considerando NAT o VPN, y sustituya public por la zona activa verificada. La regla solo cubre IPv4 y no anula otros permisos amplios. Tras probar una conexión nueva, guarde únicamente esa regla repitiéndola con --permanent. Retire un permiso general de SSH solo como cambio separado, con origen y recuperación por consola confirmados.

En el servidor remoto, no se deben eliminar las reglas existentes antes de verificar que la nueva regla de permiso coincida con la fuente de conexión real. Es más seguro probar primero con una regla en tiempo de ejecución y asegurar un medio de recuperación de la consola.

Separe usuarios y claves

• Se emite una clave diferente para cada persona y, al momento de la salida o cambio de rol, solo se desactiva esa clave.
• Se distinguen las claves de automatización de las claves de gestión interactivas de las personas.
• Se protege la clave privada con una frase de paso y el reenvío del agente SSH solo se usa cuando es necesario.
• Se recopilan y se generan alertas centralizadas de los registros de SSH y los intentos de autenticación anormal.

En caso de que sea absolutamente necesario abrir el inicio de sesión con contraseña de root

Si se activa junto con la autenticación por contraseña en PermitRootLogin yes, los ataques de fuerza bruta y la fuga de credenciales pueden llevar inmediatamente a los privilegios máximos. Si existen razones inevitables como equipos antiguos, utilice VPN o una red de gestión, un tiempo de aplicación corto, contraseñas temporales fuertes y monitoreo concentrado, sin exponer directamente a Internet.

PermitRootLogin yes
PasswordAuthentication yes
AuthenticationMethods any

Modifique los valores efectivos del mismo bloque Match de root; añadir valores duplicados en otro archivo no garantiza cambiarlos. Si permanece AuthenticationMethods publickey, permitir contraseña con otras opciones no basta. El estado de la cuenta, los módulos de autenticación conectables (PAM) y el cortafuegos también influyen. Revierta la excepción al terminar y compruebe la política y su denegación desde una conexión nueva.

Este valor es solo un ejemplo de configuración y no es una configuración recomendada. Una vez finalizado el trabajo, vuelva inmediatamente a usar solo claves o prohíba el inicio de sesión de root, y elimine las contraseñas utilizadas.

Prohibir nuevamente el inicio de sesión directo de root

Primero verifique el inicio de sesión con la nueva clave pública y sudo de la cuenta de administrador general. Devuelva el valor de PermitRootLogin del bloque Match real para root que se modificó anteriormente a no. No se restaura agregando valores duplicados en otro drop-in.

PermitRootLogin no

Después de verificar la sintaxis y los valores finales con sshd -t y con sshd -T -C para las condiciones de acceso real de root, aplíquelo al servicio en ejecución. Pruebe si el nuevo acceso de root se rechaza mientras se mantiene la sesión actual y si el administrador general aún puede acceder.

Elementos a verificar cuando surja un problema

Documentos de referencia

En el manual oficial de OpenSSH sshd_config puede verificar el significado exacto de PermitRootLogin, Match y la configuración relacionada con la autenticación.