Partimos de un servidor recién creado al que todavía se entra como root y con contraseña. El objetivo es terminar con un usuario propio, acceso solo por clave y el login de root cerrado.

1. Crear un usuario con permisos de administrador

Conviene no trabajar directamente como root, pero sí tener permisos de administrador cuando hagan falta. 

adduser usuario
usermod -aG sudo usuario

Comprobamos que el usuario pertenece al grupo sudo:

groups usuario

2. Generar el par de claves

Las claves se crean en el equipo local, no en el servidor:

ssh-keygen -t ed25519 -C "mi_equipo"

Quedan guardadas en C:\Users\usuario\.ssh en Windows, o en ~/.ssh en Linux y macOS. Después, en el servidor, creamos la carpeta .ssh dentro de /home/usuario/, y dentro un fichero authorized_keys con el contenido de la clave pública (el fichero .pub).

Importante

Hay que subir la clave por SFTP conectándose con el usuario creado, no como root. Si no, la clave quedará en el directorio de root y solo servirá para entrar como root.

3. Ajustar los permisos

SSH ignora las claves si los permisos son demasiado abiertos:

chmod 700 /home/usuario/.ssh
chmod 600 /home/usuario/.ssh/authorized_keys

Para verificarlo:

ls -la /home/usuario/.ssh

drwx------ 2 usuario usuario 4096 ... .
-rw------- 1 usuario usuario  100 ... authorized_keys

4. Probar la conexión

Desde el equipo local, antes de cerrar nada. Si entra sin pedir la contraseña del usuario —o pidiendo solo la passphrase de la clave, si le pusiste una— está funcionando: 

ssh usuario@IP_DEL_SERVIDOR

Para configurar las claves en Termius y Filezilla, ver Configurar claves SSH en Termius y Filezilla.

5. Bloquear el login de root y por contraseña

Antes de seguir

Deja la sesión actual abierta hasta haber comprobado que entras por clave desde otra ventana. Si te equivocas aquí, puedes quedarte fuera del servidor.

Editamos la configuración de SSH:

sudo nano /etc/ssh/sshd_config
PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no

6. Comprobar que nada pisa la configuración

sshd_config incluye los ficheros de sshd_config.d/, y lo que digan ellos puede ganar. Vamos a ver qué hay: 

grep -r -E "PermitRootLogin|PasswordAuthentication" /etc/ssh/sshd_config.d/

/etc/ssh/sshd_config.d/50-cloud-init.conf:PasswordAuthentication yes

Ese fichero estaba activando de nuevo el acceso por contraseña, daba igual lo que pusiéramos en sshd_config. Lo cambiamos: 

sudo nano /etc/ssh/sshd_config.d/50-cloud-init.conf

Ponemos PasswordAuthentication no y guardamos. Como lo más probable es que se regenere tras un reinicio, añadimos además un fichero propio que se lee antes y por tanto gana: 

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf
PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no

Y confirmamos que ese directorio se incluye:

grep -i "^Include" /etc/ssh/sshd_config

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

7. Validar y recargar

Primero validamos la sintaxis; si hay un error, mejor saberlo antes de recargar:

sudo sshd -t
sudo systemctl reload ssh

Y comprobamos la configuración que de verdad está aplicando el servidor:

sudo sshd -T | grep -E "permitrootlogin|passwordauthentication|pubkeyauthentication"

permitrootlogin no
pubkeyauthentication yes
passwordauthentication no

A partir de aquí, al servidor solo se entra con la clave privada.

Tecnologías

  • SSH
  • ed25519
  • Linux
  • Hardening