Configurar el servidor SSH de forma segura

Módulo 2: SSH y claves · Tiempo de lectura: 12 minutos

Objetivo de aprendizaje: Después de esta lección podrá desactivar el inicio de sesión con contraseña y el inicio de sesión de root con contraseña, comprobar qué configuración se aplica realmente y hacerlo sin quedarse fuera de su servidor.

Conceptos clave: sshd, sshd_config, sshd_config.d, cuenta el primer valor, PasswordAuthentication, KbdInteractiveAuthentication, PermitRootLogin, AuthenticationMethods, AllowUsers, sshd -t, sshd -T, segunda sesión, cloud-init, ssh.socket

Primero, la red de seguridad

En esta lección cierra una puerta por la que usted mismo tiene que pasar. Un error tipográfico puede hacer que ya no pueda entrar. Por eso, antes de empezar, asegúrese siempre de lo siguiente:

1. Dos claves funcionan (lección 2.1), y ha comprobado en una ventana nueva que puede iniciar sesión con una clave.
2. Una instantánea (snapshot) de su VPS. En WebOké la crea en la pantalla del VPS; en otros proveedores también se llama snapshot o imagen. Si algo sale mal, la restaura.
3. Conoce la consola de su proveedor: desde ahí puede entrar sin SSH.
4. Su sesión SSH actual permanece abierta hasta el final. Una sesión en curso sigue funcionando aunque cambie la configuración o recargue el servicio. Pruebe cada cambio en una segunda ventana.

Dónde está la configuración

El servidor SSH se llama sshd. Su configuración está en /etc/ssh/sshd_config. En Debian y Ubuntu, al principio de ese archivo aparece esta línea:

Include /etc/ssh/sshd_config.d/*.conf

Por tanto, todos los archivos con .conf de la carpeta sshd_config.d se leen antes que el resto del archivo principal, en orden alfabético. Eso resulta práctico: coloca su propia configuración en un archivo aparte y no toca el archivo principal, de modo que una actualización del paquete no afecta a sus cambios.

Pero tiene una consecuencia que sorprende a mucha gente. En sshd_config se aplica esta regla: para cada opción cuenta el primer valor que encuentra sshd. Las líneas posteriores con la misma opción se ignoran. Quien escribe PasswordAuthentication no al final de sshd_config no se impone, por tanto, a un archivo de sshd_config.d que diga yes.

La trampa de cloud-init

Muchas imágenes de VPS se configuran en el primer arranque mediante cloud-init. Según cómo estén configuradas la imagen y la instalación, cloud-init escribe un archivo como /etc/ssh/sshd_config.d/50-cloud-init.conf que contiene, por ejemplo:

PasswordAuthentication yes

Como ese archivo se lee antes que el archivo principal, el inicio de sesión con contraseña queda activado, ponga lo que ponga en sshd_config. Así que no lo dé por supuesto: compruébelo.

root@web1:~# grep -ri passwordauthentication /etc/ssh/sshd_config /etc/ssh/sshd_config.d/
/etc/ssh/sshd_config:#PasswordAuthentication yes
/etc/ssh/sshd_config.d/50-cloud-init.conf:PasswordAuthentication yes

Hay dos soluciones limpias: cambie ese archivo a no, o coloque su propia configuración en un archivo que vaya antes en el orden alfabético, como 00-beveiliging.conf. Un archivo 99-mijn.conf precisamente no funciona, porque entonces cloud-init ya se ha impuesto.

Las opciones que importan

Cree su propio archivo:

root@web1:~# nano /etc/ssh/sshd_config.d/00-beveiliging.conf

con este contenido:

# Inicio de sesión solo con clave
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password

¿Qué significa cada línea?

• PasswordAuthentication no: el servidor ya no acepta contraseñas. El valor predeterminado de OpenSSH es yes.
• KbdInteractiveAuthentication no: "keyboard-interactive" es una segunda forma de pedir una contraseña, a través de PAM. Si la deja activada, alguien podría seguir probando una contraseña, aunque PasswordAuthentication esté en no. En manuales antiguos esta opción se llama ChallengeResponseAuthentication; desde OpenSSH 8.7 es un nombre alternativo obsoleto para lo mismo. Debian ya la pone en no de forma predeterminada, pero inclúyala igualmente: así queda claro y también es correcto en otros sistemas.
• PermitRootLogin prohibit-password: root puede iniciar sesión, pero solo con una clave. Es el valor predeterminado desde OpenSSH 7.0. Más estricto es PermitRootLogin no: root no puede entrar por SSH en absoluto; usted inicia sesión como usuario normal y utiliza sudo (lección 3.2). Ponga no solo cuando esté seguro de que funcionan el inicio de sesión con ese usuario y sudo.

Opcional, para quien quiera ir más allá:

AllowUsers anna
AuthenticationMethods publickey

AllowUsers solo deja entrar a los usuarios indicados; cualquier otro nombre se rechaza, aunque tenga una clave válida. Es útil, pero no se olvide de usted mismo, ni de ampliarlo cuando añada un segundo administrador. AuthenticationMethods publickey indica en una sola línea que solo valen las claves.

Probar, aplicar, comprobar

Primero deje que sshd compruebe el archivo. Esto no inicia nada ni cambia nada:

root@web1:~# sshd -t
root@web1:~#

Si no hay salida, no hay errores. Si hay un error tipográfico, verá la línea y el archivo. Solo entonces recargue el servicio:

root@web1:~# systemctl reload ssh

En Debian y Ubuntu el servicio se llama ssh; en AlmaLinux y Rocky Linux, sshd.

A continuación compruebe qué valor se aplica realmente. sshd -T muestra la configuración completa y resuelta, con todos los archivos Include procesados:

root@web1:~# sshd -T | grep -Ei 'passwordauth|kbdinteractive|permitrootlogin'
permitrootlogin without-password
passwordauthentication no
kbdinteractiveauthentication no

(without-password es el nombre antiguo de prohibit-password. Las versiones de OpenSSH anteriores a la 10.1, como las de Debian 13 y Ubuntu 24.04, todavía muestran el nombre antiguo; las más recientes muestran prohibit-password. Significa lo mismo.)

Y ahora lo más importante: pruebe en una segunda ventana, mientras la primera sigue abierta.

anna@laptop:~$ ssh anna@192.0.2.10
anna@web1:~$

Si funciona, intente iniciar sesión a propósito con una contraseña. Esto debe fallar:

anna@laptop:~$ ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no anna@192.0.2.10
anna@192.0.2.10: Permission denied (publickey).

Detrás de Permission denied aparecen entre paréntesis los métodos de inicio de sesión que el servidor todavía ofrece. Si solo aparece publickey, está bien. Si también aparece password o keyboard-interactive, en algún sitio sigue aplicándose otro valor: vuelva a comprobarlo con sshd -T.

Precisamente esa lista es la que comprueba también el ejercicio del curso, desde fuera. En cada conexión, su cliente SSH pregunta primero qué métodos están permitidos, con una solicitud del tipo "none". El servidor responde con la lista, sin que se pruebe ninguna contraseña ni clave.

Ubuntu 24.04 y posteriores: ssh.socket

En Ubuntu desde la versión 22.10, quien escucha en el puerto 22 no es sshd, sino systemd, a través de ssh.socket. Solo cuando llega una conexión, systemd inicia el servicio SSH. Para la configuración de esta lección eso no cambia nada: basta con systemctl reload ssh o restart ssh.

Sí importa si cambia el puerto o la dirección de escucha (Port, ListenAddress). Desde Ubuntu 24.04, systemd lee esos valores de sshd_config, pero solo después de:

root@web1:~# systemctl daemon-reload
root@web1:~# systemctl restart ssh.socket

Si lo olvida, el servidor sigue escuchando en el puerto antiguo. Peor aún: si primero configura su firewall para un puerto nuevo y SSH se queda en el antiguo, se queda fuera. Compruebe siempre con ss -tlnp | grep ssh en qué puerto se escucha realmente (lección 5.1), y abra el puerto nuevo en su firewall antes de cerrar el antiguo. Si tiene sentido usar otro puerto, lo verá en la lección 2.3.

Si aun así algo sale mal

Si ya no puede entrar, abra la consola de su proveedor, inicie sesión como root (con la contraseña, porque la consola es un "teclado conectado al servidor" y no SSH) y deshaga los cambios de su archivo:

root@web1:~# mv /etc/ssh/sshd_config.d/00-beveiliging.conf /root/
root@web1:~# systemctl reload ssh

Si tampoco funciona, restaure la instantánea. En WebOké también puede establecer una nueva contraseña de root en la pantalla del VPS; otros proveedores suelen tener un botón similar o un modo de rescate (rescue).

En AlmaLinux y Rocky Linux

El servicio se llama sshd (systemctl reload sshd). Allí también hay un Include /etc/ssh/sshd_config.d/*.conf al principio y el sistema incluye sus propios archivos en esa carpeta; se aplica la misma regla de "cuenta el primer valor". Si cambia el puerto, SELinux también debe permitir ese puerto (semanage port -a -t ssh_port_t -p tcp 2222) y firewalld debe abrirlo.

Resumen

• En sshd_config cuenta el primer valor; los archivos de sshd_config.d se leen primero. Coloque su propia configuración en un archivo como 00-beveiliging.conf.
• Ponga PasswordAuthentication no y también KbdInteractiveAuthentication no; root solo con una clave (prohibit-password) o en absoluto (no).
• Compruebe con sshd -t antes de recargar y con sshd -T qué valor se aplica realmente; preste atención a un 50-cloud-init.conf.
• Pruebe en una segunda ventana y mantenga abierta la primera sesión. Conozca la consola y cree una instantánea de antemano.
• En Ubuntu 24.04+, cambiar de puerto requiere systemctl daemon-reload y systemctl restart ssh.socket.

Cuestionario

Ejercicio

Ejercicio Z2.2: El inicio de sesión con contraseña está desactivado. Desactive el inicio de sesión con contraseña y keyboard-interactive como se explica en esta lección, y después deje que el programa lo compruebe desde fuera. Introduzca la dirección IP o el nombre de host de su servidor, el puerto SSH (22 por defecto) y el nombre de usuario con el que usted inicia sesión (por ejemplo anna, no root ni un nombre inventado). El programa no inicia sesión: solo pregunta, como hace cualquier cliente SSH antes de iniciar sesión, qué métodos de inicio de sesión ofrece su servidor para ese usuario. El resultado correcto es: solo publickey.

Para saber más

Los pasos de estos artículos se refieren a la pantalla del VPS de WebOké; en otros proveedores funciona de forma similar.

• Proteger su VPS: los primeros cinco minutos
• Sin acceso a su VPS: ¿qué hacer?
• Snapshots y copias de seguridad de su VPS
• Manual de sshd_config: https://man.openbsd.org/sshd_config
• Ubuntu: SSHd now uses socket-based activation: https://discourse.ubuntu.com/t/sshd-now-uses-socket-based-activation-ubuntu-22-10-and-later/30189