Proteger SSH¶
SSH es la puerta de entrada principal a un servidor remoto. Por defecto, muchas imágenes cloud vienen con acceso root habilitado y autenticación por contraseña — dos vectores de ataque que conviene cerrar cuanto antes.
Qué hace¶
El hardening de SSH se basa en tres mecanismos:
- Quitar acceso root — nadie puede entrar directamente como superusuario.
- Clave pública en vez de contraseña — las contraseñas se pueden adivinar; las claves criptográficas no.
- Grupo restringido — solo los usuarios que pertenezcan al grupo
sshuserspueden conectarse.
Todo se configura en un único fichero aparte (00-hardening.conf), sin tocar sshd_config principal. Así se mantienen las actualizaciones del sistema limpias y la config propia, separada.
Proteger SSH¶
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.confContenido por defecto:
PermitRootLogin no PasswordAuthentication yes AllowUsers hostingPuerto 22 se mantiene — cambiarlo no aporta seguridad real y es trivialmente detectable.
PasswordAuthentication yeses 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 no99-En
sshd_config.d/los ficheros deIncludese leen en orden alfabético y, a diferencia desysctl.d/olimits.d/, gana el primer valor encontrado, no el último. Muchas imágenes cloud (DigitalOcean, Hetzner...) traen un50-cloud-init.confconPasswordAuthentication yesexplícito — si tu fichero se llamara99-hardening.confse leería después y tunose ignoraría en silencio (sshd -Tseguiría diciendoyes). Llamándolo00-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ñadir claves públicas¶
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_ed25519de 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
hostingya creado y conPasswordAuthentication yes, del paso base de arriba):ssh-copy-id hosting@<ip-servidor>Si
ssh-copy-idno está disponible (por ejemplo en Windows sin WSL), hazlo a mano:ssh hosting@<ip-servidor> \ 'mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys' \ < ~/.ssh/id_ed25519.pub -
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
PasswordAuthenticationen 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.confContenido final:
# Custom config AllowGroups sshusers AllowUsers hosting ClientAliveCountMax 2 ClientAliveInterval 300 LoginGraceTime 30 MaxAuthTries 3 PasswordAuthentication no PermitRootLogin no PubkeyAuthentication yesEsto sustituye el
PasswordAuthentication yesy elAllowUserssueltos 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¶
sudo sshd -T | grep passwordauth
sudo sshd -T | grep permitroot
Debe salir passwordauthentication no y permitrootlogin no.
Y ahora qué
SSH está protegido. El siguiente paso es configurar el Firewall para abrir solo los puertos necesarios.