2. Proteger SSH¶

2026-09-03

Quitar acceso root, mantener puerto 22. Todo se hace en un único fichero de configuración aparte, sin tocar sshd_config directamente.

Crear el drop-in de hardening:
```
sudo vim /etc/ssh/sshd_config.d/00-hardening.conf
```
Contenido por defecto:
```
PermitRootLogin no
PasswordAuthentication yes
AllowUsers hosting
```
Puerto 22 se mantiene — cambiarlo no aporta seguridad real y es trivialmente detectable.

PasswordAuthentication yes es el punto de partida, para no perder el acceso al servidor. En cuanto tengas tu clave pública desplegada, aplica el añadido de abajo para desactivarla.

Por qué 00- y no 99-

En sshd_config.d/ los ficheros de Include se leen en orden alfabético y, a diferencia de sysctl.d/ o limits.d/, gana el primer valor encontrado, no el último. Muchas imágenes cloud (DigitalOcean, Hetzner...) traen un 50-cloud-init.conf con PasswordAuthentication yes explícito — si tu fichero se llamara 99-hardening.conf se leería después y tu no se ignoraría en silencio (sshd -T seguiría diciendo yes). Llamándolo 00- te aseguras de que se lee el primero y gana siempre.
Validar la sintaxis antes de recargar:
```
sudo sshd -t
```
Aplicar cambios (no corta la sesión actual, a diferencia de restart):
```
sudo service sshd reload
```
Antes de cerrar la sesión actual, abrir una terminal nueva y confirmar que entras con hosting:
```
ssh hosting@<ip-servidor>
```

Añadido: solo claves, sin contraseña (recomendado)¶

Genera tu par de claves, cópialo al servidor y luego cierra el acceso por contraseña. Se amplía el mismo fichero de arriba — no hace falta crear uno nuevo.

En tu máquina local (no en el servidor), generar el par de claves si todavía no tienes una (si ya tienes ~/.ssh/id_ed25519 de otro proyecto, puedes reutilizarla y saltar al paso 2):
```
ssh-keygen -t ed25519 -C "hosting@<nombre-servidor>"
```
Acepta la ruta por defecto (~/.ssh/id_ed25519) pulsando Enter y pon una passphrase (recomendado; te la pedirá el agente SSH, no en cada conexión, una vez lo configures).
En tu máquina local, copiar la clave pública al servidor (con hosting ya creado y con PasswordAuthentication yes, del paso base de arriba):
```
ssh-copy-id hosting@<ip-servidor>
```
Si ssh-copy-id no está disponible (por ejemplo en Windows sin WSL), hazlo a mano:
```
cat ~/.ssh/id_ed25519.pub | ssh hosting@<ip-servidor> \
 'mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys'
```
En tu máquina local, confirmar que entras con la clave (sin que pida contraseña):
```
ssh -o PasswordAuthentication=no hosting@<ip-servidor>
```
Si esto falla, no sigas con el resto de este bloque — revisa la copia de la clave antes de desactivar PasswordAuthentication en el servidor o te quedas fuera.

En el servidor, crear el grupo dedicado y añadir a hosting:

sudo groupadd sshusers
sudo usermod -aG sshusers hosting

Editar el drop-in ya creado:

sudo vim /etc/ssh/sshd_config.d/00-hardening.conf

Contenido final:

# Custom config
AllowGroups sshusers
AllowUsers hosting
ClientAliveCountMax 2
ClientAliveInterval 300
LoginGraceTime 30
MaxAuthTries 3
PasswordAuthentication no
PermitRootLogin no
PubkeyAuthentication yes

Esto sustituye el PasswordAuthentication yes y el AllowUsers sueltos de arriba, en el mismo fichero.

Validar la sintaxis antes de recargar (evita quedarte fuera si hay un error):
```
sudo sshd -t
```
Recargar (no corta las sesiones activas, a diferencia de restart):
```
sudo service sshd reload
```
Antes de cerrar la sesión actual, abrir una terminal nueva y confirmar que entras con clave, sin contraseña:
```
ssh hosting@<ip-servidor>
```

Verificar que la config activa es la esperada:

sudo sshd -T | grep passwordauth
sudo sshd -T | grep permitroot