Endurecimiento de acceso SSH deshabilitando autenticación por contraseña y root

Endurecimiento de acceso SSH deshabilitando autenticación por contraseña y root

El acceso SSH es el vector más expuesto en muchos servidores dedicados. Este artículo, dirigido a administradores y responsables de infraestructura, detalla pasos prácticos y seguros para deshabilitar la autenticación por contraseña y el login directo de root, implementar autenticación por claves y probar cambios sin dejar el servidor inaccesible.

Por qué deshabilitar contraseña y root en SSH

Los ataques por fuerza bruta y el abuso de credenciales comprometidas son persistentes. Deshabilitar la autenticación por contraseña reduce significativamente la superficie de ataque; impedir el acceso directo de root obliga a usar cuentas con control y auditoría. Estas prácticas están alineadas con las recomendaciones de seguridad y gestión de identidades en organismos como NIST y buenas prácticas de seguridad promovidas por OWASP.

Requisitos previos y buenas prácticas

  • Asegúrate de tener acceso a una consola alternativa (IPMI, panel de proveedor o acceso físico) en caso de error.
  • Cuenta con un usuario con privilegios sudo distinto de root.
  • Haz una copia de seguridad del archivo /etc/ssh/sshd_config antes de modificarlo.
  • Comprueba el firewall y que el puerto SSH (por defecto 22) está permitido desde tu IP de administración.

Generar y desplegar claves SSH (recomendado: ed25519)

Las claves públicas son más seguras que las contraseñas, especialmente con tipos modernos como ed25519 o RSA de 3072/4096 bits si necesitas compatibilidad.

Generar clave en tu equipo local

  • Comando recomendado: ssh-keygen -t ed25519 -C "admin@tu-dominio"
  • Si tu entorno no soporta ed25519: ssh-keygen -t rsa -b 4096 -C "admin@tu-dominio"

Instalar la clave en el servidor

  • Usa ssh-copy-id para facilitar la instalación: ssh-copy-id -i ~/.ssh/id_ed25519.pub usuario@servidor
  • Instalación manual (si no hay ssh-copy-id):
    • ssh usuario@servidor (con contraseña temporal)
    • En el servidor: mkdir -p ~/.ssh && chmod 700 ~/.ssh
    • Agregar clave: echo 'TU_CLAVE_PUBLICA' >> ~/.ssh/authorized_keys
    • Permisos: chmod 600 ~/.ssh/authorized_keys

Permisos erróneos en ~/.ssh o authorized_keys causan que OpenSSH rechace las claves; siempre verifica permisos tras copiar.

Modificar /etc/ssh/sshd_config de forma segura

Antes de cualquier cambio, guarda una copia:

  • sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

Ediciones recomendadas (añadir o ajustar):

  • PermitRootLogin no — impide login directo de root.
  • PasswordAuthentication no — deshabilita autenticación por contraseña.
  • ChallengeResponseAuthentication no
  • PubkeyAuthentication yes
  • UsePAM yes — si usas PAM (ten en cuenta interacciones con 2FA).
  • Opcionalmente: AllowUsers admin@IP o AllowGroups sshadmins para restringir usuarios.

Ejemplo de cambio automático (haz backup primero):

  • sudo sed -i.bak -e 's/^#PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
  • sudo sed -i -e 's/^#PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config

Reinicia el servicio SSH:

  • sudo systemctl restart sshd (o sudo systemctl restart ssh en algunas distribuciones)
  • Verifica: sudo ss -tulpn | grep sshd o sudo systemctl status sshd

Probar cambios sin bloquearte: metodología segura

Nunca cierres tu sesión administrativa hasta confirmar que una nueva conexión funciona. Procedimiento recomendado:

  • Desde tu estación, abre una nueva terminal e intenta ssh -v usuario@servidor. El flag -v ayuda al diagnóstico.
  • Si la conexión falla, no cierres la sesión que editó sshd_config; restaura el archivo de backup y reinicia el servicio: sudo mv /etc/ssh/sshd_config.bak /etc/ssh/sshd_config && sudo systemctl restart sshd.
  • Si no hay consola alternativa, solicita acceso al panel de tu proveedor (rescue/IPMI) antes del cambio.

Medidas adicionales de endurecimiento

  • Habilitar Fail2ban para bloquear IPs con intentos repetidos.
  • Aplicar reglas de firewall estrictas (ufw, nftables o iptables) limitando acceso SSH por IP cuando sea posible.
  • Usar AllowUsers o AllowGroups en sshd_config para limitar usuarios con acceso remoto.
  • Considerar autenticación por certificados de OpenSSH para entornos con rotación y control centralizado.
  • Implementar 2FA (Google Authenticator, YubiKey) si la política lo requiere; tenga en cuenta interacción con UsePAM.
  • Registrar y monitorizar accesos con alertas (SIEM o syslog centralizado).

Errores comunes y cómo recuperarse

  • Clave rechazada: revisa permisos (~/.ssh a 700, authorized_keys a 600) y el contenido de la clave.
  • Registro de errores: sudo journalctl -u sshd -e o sudo tail -n 200 /var/log/auth.log para pistas.
  • Si te bloqueas sin consola, utiliza el modo rescue del proveedor o acceso IPMI para restaurar el archivo de configuración desde la copia de seguridad.
  • SELinux: si está activado, asegúrate del contexto correcto: restorecon -Rv ~/.ssh.

Checklist previa al cambio

  • Tener al menos un usuario sudo con clave pública instalada y verificada.
  • Backup de /etc/ssh/sshd_config y plan de recuperación (consola/IPMI).
  • Comprobar reglas de firewall y origen permitido para SSH.
  • Prueba de conexión desde una nueva sesión antes de cerrar la original.

Conclusión

Deshabilitar la autenticación por contraseña y el acceso directo de root en SSH eleva de forma notable la seguridad de tus servidores dedicados. La práctica correcta combina claves robustas (preferiblemente ed25519), políticas de acceso restringido, monitorización y un procedimiento de pruebas seguro para evitar quedarte sin acceso. Implementa los cambios siguiendo la checklist descrita y mantén copias de seguridad y métodos de recuperación disponibles. Estas medidas, junto con herramientas como Fail2ban y un firewall bien configurado, reducen drásticamente el riesgo de intrusiones y facilitan auditorías y control operacional.

Para ampliar buenas prácticas y guías más formales, consulta las recomendaciones de NIST y los principios de seguridad de OWASP.

Tags: