Desactivar la autenticación SSH por contraseña sin quedarte fuera

Solo-claves es el cambio individual más potente en un servidor SSH expuesto. El orden seguro para hacerlo, las líneas de configuración que de verdad importan, y lo que no arregla.

7 min de lectura

Por qué es el cambio de mayor valor

Casi todo compromiso de un servidor Linux expuesto a internet empieza con una contraseña válida — adivinada, reutilizada de la filtración de otro, o conseguida por phishing. Desactiva la autenticación por contraseña y toda esa categoría deja de ser posible. No más difícil: imposible. No hay contraseña que adivinar.

Nada más en una lista de endurecimiento se le acerca por el esfuerzo que exige. Son dos líneas de configuración y una recarga.

Se pospone por miedo a hacerlo mal, y ese riesgo es real: equivócate en el orden y te desconectas de una máquina a la que solo llegas por SSH. El resto de esta guía es ese orden.

La secuencia segura

Cada paso se verifica antes de dar el siguiente, y la sesión en la que estás permanece abierta todo el tiempo. No la cierres hasta el final.

Primero, genera una clave si no tienes. Ed25519 es la opción por defecto actual: más corta, más rápida y al menos tan fuerte como una RSA de 4096 bits.

bash
# 1. En tu propia máquina, no en el servidor
ssh-keygen -t ed25519 -C "tu@example.com"

# 2. Copiar la clave pública al servidor (pide tu contraseña una última vez)
ssh-copy-id user@server

# 3. Verificar desde una SEGUNDA terminal, sin cerrar la primera
ssh -o PreferredAuthentications=publickey -o PasswordAuthentication=no user@server

La configuración que de verdad importa

Solo después de que el paso 3 funcione, edita la configuración del servidor. En distribuciones modernas el archivo a editar puede no ser sshd_config: muchas incluyen un directorio /etc/ssh/sshd_config.d/ cuyos archivos se incluyen y pueden sobrescribir lo que escribas más arriba.

Cuatro ajustes hacen el trabajo:

bash
# /etc/ssh/sshd_config.d/10-hardening.conf   (o directamente sshd_config)
PasswordAuthentication no
KbdInteractiveAuthentication no    # nombre antiguo: ChallengeResponseAuthentication
PermitRootLogin prohibit-password  # o 'no' si root nunca entra directamente
PubkeyAuthentication yes

# Comprueba siempre la configuración antes de recargar — esto caza erratas
# que, si no, impedirían que sshd volviera a levantarse:
sudo sshd -t

# Luego reload en vez de restart: las sesiones existentes sobreviven
sudo systemctl reload ssh    # o 'sshd' en la familia RHEL

Verificar que ha surtido efecto

No te fíes del archivo de configuración: pregúntale a sshd a qué ha resuelto realmente. sshd -T imprime la configuración efectiva tras todas las inclusiones y sobrescrituras:

bash
sudo sshd -T | grep -iE 'passwordauthentication|kbdinteractiveauthentication|permitrootlogin'
# esperado:
#   passwordauthentication no
#   kbdinteractiveauthentication no
#   permitrootlogin prohibit-password

# Y demuéstralo desde fuera: esto debe ser rechazado ahora
ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password user@server

Lo que no arregla

Solo-claves elimina el riesgo de adivinación. No elimina el tráfico ni todos los caminos de entrada.

Los bots siguen conectándose. No conocen tu configuración, así que siguen ofreciendo contraseñas y siendo rechazados — cada intento cuesta igualmente una conexión TCP, un fork de sshd y una línea de registro. Tu registro de autenticación se sigue llenando de ruido, y el evento que necesitabas se sigue perdiendo. Algo tiene que bloquear los orígenes de todos modos.

Y una clave privada es un archivo. En un portátil robado, en un repositorio donde alguien la subió por error, en el entorno de un runner de CI. Protege las claves con frase de paso, mantenlas fuera de máquinas compartidas y rótalas cuando alguien se vaya — una clave filtrada es exactamente igual de mala que una contraseña filtrada.

Tampoco hace nada contra un sshd sin parchear, un servicio expuesto en otro puerto o una aplicación vulnerable en el mismo host. Es el mejor cambio disponible, y es un control entre varios.

La pieza complementaria

Con las contraseñas desactivadas, queda el volumen. SSH Protector lee el mismo flujo de autenticación, banea los orígenes que siguen llegando — por subred, de forma permanente, restaurados al arrancar — y pone tu propia dirección en la lista blanca antes de bloquear nada.

Detecta el puerto SSH real desde la configuración de sshd en lugar de asumir el 22, así que un servidor que ya has movido queda cubierto sin configurar nada.

Solo-claves para el riesgo. Baneo de orígenes para la carga, y para el registro legible que te deja notar el único evento que importa.

FAQ

¿Cómo desactivo la autenticación SSH por contraseña de forma segura?
Genera una clave, cópiala con ssh-copy-id, y verifica desde una segunda terminal que el inicio de sesión solo con clave funciona mientras tu primera sesión sigue abierta. Solo entonces pon PasswordAuthentication no y KbdInteractiveAuthentication no, ejecuta sshd -t para comprobar la sintaxis, y recarga en vez de reiniciar. Mantener abierta la primera sesión es lo que hace recuperable un error.
¿Por qué SSH sigue pidiendo contraseña tras poner PasswordAuthentication no?
Casi siempre por una de dos razones. O KbdInteractiveAuthentication sigue en yes y PAM ofrece la petición por otro mecanismo, o un archivo de /etc/ssh/sshd_config.d/ se incluye después de tu cambio y lo sobrescribe. Ejecuta sudo sshd -T | grep -i passwordauth para ver el valor al que sshd resolvió realmente.
¿Ed25519 o RSA?
Ed25519, salvo que algo en tu entorno no lo soporte. Las claves son mucho más cortas, la verificación más rápida, y la seguridad al menos equivalente a una RSA de 4096 bits. RSA sigue siendo un respaldo válido para equipos antiguos y clientes heredados; si lo usas, genera al menos 4096 bits.
¿El SSH solo-claves detiene los intentos de fuerza bruta?
Hace que no puedan tener éxito nunca, que es el objetivo. No reduce su número: los bots no tienen forma de conocer tu configuración y siguen conectándose y ofreciendo contraseñas indefinidamente. Sigues pagando cada intento en conexiones, forks y líneas de registro, así que bloquear los orígenes sigue mereciendo la pena.

Gestiona el tráfico que solo-claves deja atrás

Baneos por subred, lista blanca primero, el puerto SSH real detectado por ti. Un servidor gratis para siempre, sin tarjeta.