Endurecimiento de SSH y gestión de claves: servidores bastión, autoridades de certificación y rotación de claves

En muchos entornos, SSH sigue siendo el acceso operativo principal para Linux-Server, hosts virtuales, gateways de red y también para hosts Docker. Precisamente por ello, SSH-Hardening no es una tarea de «configurar una vez y olvidarse», sino una interacción entre endurecimiento del protocolo, rutas de acceso, identidades (claves/certificados) y un ciclo de vida fiable para el material de claves. Quien solo ajusta elementos aislados (p. ej. «desactivar Root-Login»), pero tolera proliferación de claves, falta de rotación o rutas de salto no controladas, solo traslada riesgos.

Este artículo muestra una arquitectura objetivo práctica con Bastion-Host (Jump Host como punto de entrada central), SSH Certificate Authority (CA para firmar certificados SSH de corta duración) y Key-Rotation como proceso operativo planificado. El foco está en operación, administración, auditabilidad, resolución de problemas, errores habituales y una estrategia de retroceso que no tendrá que improvisar durante un incidente.

Por qué el SSH-Hardening suele fracasar sin gestión de claves

SSH en sí es criptográficamente sólido, pero en la práctica suele fallar en tres puntos:

• Caos de identidades: claves personales de larga duración sin caducidad, copiadas con frecuencia, sin visión centralizada.
• Rutas incontroladas: accesos directos desde redes arbitrarias a sistemas productivos, a menudo además mediante excepciones de VPN o aperturas temporales de cortafuegos.
• Débil disciplina operativa: sin rotación, sin posibilidad de revocación en minutos, sin cambios rastreables en authorized_keys.

El resultado son escalados de privilegios silenciosos, procesos de offboarding complicados, MTTR elevado en incidentes (porque no está claro qué clave sigue funcionando) y brechas en los requisitos de cumplimiento y auditoría.

Visión objetivo: Bastion-Host, SSH-CA y accesos de corta duración

Una visión objetivo práctica no es un «Big Bang», sino que puede implementarse de forma incremental:

• Bastion-Host: un punto de entrada endurecido y estrechamente monitorizado, por el que pasan las conexiones SSH hacia segmentos internos. El Bastion-Host reduce la superficie de ataque, centraliza el registro (logging) y simplifica las reglas de red.
• Certificados SSH (OpenSSH Certificates): en lugar de distribuir claves públicas en cada sistema destino, los certificados de usuario de corta duración son firmados por una SSH Certificate Authority. El sistema destino confía en la CA y determina los derechos de acceso mediante atributos del certificado y políticas locales.
• Rotación de claves (Key-Rotation): las claves de hosts, las claves de la CA y (donde aún sea necesario) las claves de usuario se rotan según reglas definidas. La rotación es un proceso operativo con puntos de medición, no solo un asunto criptográfico.

Importante: «Zero Trust» a menudo se usa como palabra de moda; en el contexto de SSH significa concretamente que debe priorizar identidad, contexto y validez (duraciones cortas) por encima de «quién está en la red, ya tiene permiso».

Endurecimiento básico de OpenSSH: sshd_config, parámetros criptográficos, superficie de ataque

La base sigue siendo el endurecimiento correcto del demonio SSH (sshd). El objetivo es: solo funciones necesarias, parámetros criptográficos seguros, vías de autenticación claras.

Principio de mínimos para autenticación y funcionalidades

Muchos riesgos surgen de una configuración de «compatibilidad a cualquier precio». Medidas típicas:

• Desactivar el acceso por contraseña (cuando sea posible organizativamente) en favor de claves o certificados.
• Controlar el inicio de sesión root (ideal: desactivarlo; alternativamente: solo vía certificado y con restricciones estrictas).
• Permitir Port-Forwarding / Tunneling de forma selectiva, en lugar de activarlo de forma global.
• Asignar permisos de inicio de sesión por grupos en lugar de por cuentas individuales.

# Ejemplo: hardening conservador de sshd (ajustar según sus políticas)
# Datei: /etc/ssh/sshd_config

Protocol 2
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes

# Permitir únicamente cuando realmente lo necesite
AllowTcpForwarding no
X11Forwarding no
PermitTunnel no

# Reducir la superficie de ataque expuesta
MaxAuthTries 4
LoginGraceTime 30
ClientAliveInterval 300
ClientAliveCountMax 2

# Controlar el acceso mediante políticas (ejemplo)
AllowGroups ssh-admins ssh-ops

# Logging: para trazabilidad (sin saturación de logs)
LogLevel VERBOSE

Por qué funciona: Cada vía de autenticación desactivada es un vector de ataque menos (Credential Stuffing, contraseñas débiles, phishing). Las opciones de forwarding reducidas evitan que SSH se utilice como «túnel universal» para movimientos laterales.

Cuándo falla: Cuando tenga automatizaciones antiguas en paralelo (p. ej. copias de seguridad/despliegues) que todavía requieran inicio de sesión por contraseña o port-forwarding. Por eso: antes de desactivar, identifique las dependencias y migre en pruebas a hosts piloto.

Claves de host: huellas, algoritmos, sustituir el Trust On First Use planificado

Muchos equipos operan con «Trust On First Use» (TOFU): en el primer contacto SSH se acepta la clave del host y luego se almacena en caché. En entornos grandes eso resulta arriesgado, porque un Man-in-the-Middle en el primer contacto es difícil de detectar. Mejor: certificados de host mediante una SSH-CA o, al menos, una distribución gestionada de known_hosts.

Si rota las claves de host o migra de RSA a valores predeterminados más modernos, planifique la cascada: monitorización/automatización, bastión, gestión de configuración, portátiles de desarrolladores y clientes break-glass.

Host de bastión (Jump Host): arquitectura, operación y problemas típicos

Un host de bastión es un servidor dedicado en un segmento estrictamente controlado que actúa como la única entrada SSH a una red interna. No sustituye el endurecimiento de los sistemas destino, pero centraliza los controles de acceso y la telemetría.

Principios de red y firewall

• Entrante solo desde redes de administración definidas (p. ej. VPN, Privileged Access Segment) hacia el puerto 22 (o un puerto alternativo fijo, pero no entenderlo como «seguridad por oscuridad»).
• Saliente desde el host de bastión únicamente hacia las subredes/puertos de destino necesarios (normalmente el 22). No «el bastión puede acceder a cualquier destino».
• No hay accesibilidad directa a hosts productivos desde la red de usuarios/oficina.

Advertencia: Si administra hosts Docker, a menudo están en redes que están «de algún modo accesibles», porque los accesos de build/registry han crecido históricamente. Separe estrictamente los accesos de gestión (SSH) de las rutas de datos (registry, APIs) y evite que un build-runner comprometido pueda establecer SSH directamente en producción.

Control de sesiones y trazabilidad

Para auditorías no solo cuenta «quién estaba autorizado», sino también «quién hizo qué y cuándo». Enfoques clásicos:

• SSH-LogLevel VERBOSE para información trazable de claves/certificados.
• Reenvío centralizado de logs (p. ej. via journald/rsyslog) a un SIEM o backend de logs.
• Session Recording (entradas de teclado/salida del terminal) solo si está resuelto legal y organizativamente; técnicamente útil sobre todo en accesos altamente privilegiados.

Importante: el registro del bastión no sustituye a los logs locales en los sistemas de destino. En un incidente necesita ambas perspectivas (ingress y eventos del host).

Pasos de comprobación: validar el host bastión en el día a día

# 1) En el bastión: comprobar conexiones SSH entrantes (Linux)
ss -tnp | grep ':22 '

# 2) Journald: eventos de autenticación
journalctl -u ssh -S -2h --no-pager

# 3) Fail2ban/Rate-Limits (si aplica)
sudo fail2ban-client status sshd 2>/dev/null || true

Si ya ve aquí «ruido» (muchos fallos desde redes no esperadas), es una señal: las reglas de entrada y los controles previos (VPN, MFA, Acceso condicional) están demasiado abiertos.

SSH Certificate Authority: repartir claves ya es cosa del pasado

OpenSSH admite SSH-Zertifikate: un usuario sigue teniendo un par de claves, pero en lugar de dejar la clave pública en cada servidor en authorized_keys, se emite un certificado. Este certificado contiene, entre otras cosas, identidad (Principals), validez (NotBefore/NotAfter) y restricciones opcionales. El servidor confía en la CA mediante una entrada TrustedUserCAKeys.

Ventajas en operación

• Accesos de corta duración (p. ej. 8–24 horas) reducen considerablemente el riesgo de claves robadas.
• El offboarding es inmediato: detener la emisión por la CA; opcionalmente mantener certificados con corta validez. No hace falta tocar el «authorized_keys» en 200 hosts.
• Política central: los Principals pueden representar roles (p. ej. «ops», «db-admin»), en lugar de mantener listas por host.
• Capacidad de auditoría: los números de serie de certificados y los Principals aparecen en los logs.

Configuración básica en los hosts de destino

En los sistemas de destino define la confianza en la User-CA y mapea los Principals a permisos locales (típicamente mediante grupos Unix y reglas sudo). Concepto de ejemplo:

• La clave pública de la CA (CA-Public-Key) está almacenada como archivo en el host.
• TrustedUserCAKeys apunta a ese archivo.
• AuthorizedPrincipalsFile o AuthorizedPrincipalsCommand determina qué Principals se aceptan para cada cuenta.

# Datei: /etc/ssh/sshd_config.d/10-ca.conf (Beispielpfad, distroabhängig)

# Vertrauen in die User-CA
TrustedUserCAKeys /etc/ssh/trusted-user-ca.pub

# Principals pro Ziel-User definieren
AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u

# Zertifikate erzwingen (optional, abhängig von Ihrer Übergangsphase)
AuthenticationMethods publickey

# Principals-Dateien anlegen (Beispiel)
sudo install -d -m 0755 /etc/ssh/auth_principals

echo 'ops' | sudo tee /etc/ssh/auth_principals/admin >/dev/null
echo 'breakglass' | sudo tee /etc/ssh/auth_principals/emergency >/dev/null

sudo chmod 0644 /etc/ssh/auth_principals/*

# sshd neu laden
sudo systemctl reload sshd

Por qué funciona: El host ya no comprueba «si la clave pública está en mi archivo», sino «si este certificado está firmado por mi CA y si el Principal está permitido para esta cuenta». La CA se convierte así en la raíz de confianza central.

Cuándo falla: Cuando existe una deriva de tiempo. Los certificados están ligados al tiempo; con una hora del sistema incorrecta aparecerán como «aún no válidos» o «caducados». NTP/Chrony por tanto no es opcional. Verifique la estabilidad temporal especialmente después de VM-Snapshots/RESTores.

Proteger la clave de la CA: esto es su «Master Key»

La User-CA es de alta criticidad. Quien posea el CA-Private-Key puede firmar accesos arbitrarios. Requisitos mínimos:

• Fuera de línea u fuertemente aislada (idealmente no en el Bastion-Host mismo).
• Firma mediante un flujo de trabajo controlado (p. ej. ticket/aprobación, duraciones cortas, registro).
• Copia de seguridad y recuperación con control de acceso claro.

Muchos equipos usan aquí una PKI interna o una plataforma de secretos. Lo decisivo no es la herramienta, sino que la emisión, la validez y la revocación/paro estén operacionalizadas correctamente.

Rotación de claves: Host-Keys, User-Keys, CA-Keys – y lo que suele romperse

Rotación de claves es el reemplazo planificado de claves antes de que se comprometan. En el entorno SSH hay tres clases que debe considerar por separado:

• Host Keys: Identidad del servidor frente a los clientes. La rotación afecta a known_hosts, la automatización y el monitoreo.
• User Keys / Zertificados: Identidad de los usuarios/automatizaciones frente a los servidores. Con certificados SSH rota sobre todo la política de CA y la base de claves de usuario con menor frecuencia.
• CA Keys: Raíz de confianza. La rotación es posible, pero debe planificarse como una ventana de migración (confiar en varias CAs en paralelo).

Rotación sin tiempo de inactividad: confianza paralela y ventana de migración

Un enfoque práctico es «permitir en paralelo, luego desactivar»:

• Introducir una CA nueva y confiarla además en los hosts objetivo (TrustedUserCAKeys kann mehrere Keys enthalten, entweder in einer Datei oder über mehrere Dateien, je nach Aufbau).
• Los Clients reciben nuevos certificados de la nueva CA.
• Tras el vencimiento de los certificados antiguos y la fecha límite definida, eliminar la confianza en la CA antigua.

Para las Host-Keys se aplica un principio similar mediante known_hosts gestionados o certificados de host.

Escollos típicos en la rotación

• Automatizaciones olvidadas: CI-Runner, Backup-Server, comprobaciones de monitorización, gestión de configuración. A menudo usan sus propias claves.
• Clientes embebidos: Appliances o imágenes antiguas con entradas known_hosts duramente codificadas.
• „Aceptado una vez“: estaciones de trabajo de administradores donde se han cerrado/aceptado las advertencias de clave de host. Eso se cobra durante una rotación real.
• Deriva de tiempo (en certificados) y inconsistencias DNS/IP (desajuste de clave de host).

Implementación por etapas: de Quick Wins a la arquitectura objetivo limpia

Si hoy dispone de un entorno heterogéneo (servidores clásicos, VMs, Docker-Hosts, posiblemente Kubernetes-Nodes), un plan por etapas es más realista que una migración completa.

Etapa 1: Visibilidad e higiene

• Inventariar: ¿dónde está abierto el puerto 22? ¿Qué sistemas son accesibles directamente?
• Higiene de claves: ¿qué authorized_keys están dónde? ¿Quién las posee? ¿Hay claves compartidas?
• Centralizar el logging: al menos Bastion + clases de servidores críticas a un backend de logs.

# Grober Check: Welche Accounts haben authorized_keys?
sudo find /home /root -maxdepth 2 -type f -name authorized_keys -print

# Inhalte prüfen (Vorsicht: sensible Daten)
# Tipp: nur Fingerprints der Public Keys extrahieren
sudo awk '{print $1" "$2}' /home/*/.ssh/authorized_keys 2>/dev/null | sort -u | head

Etapa 2: Exigir el Bastion-Host

Técnicamente se impone mediante reglas de red (Security Groups/Firewall) y mediante políticas del servidor SSH en los hosts objetivo (solo la IP del Bastion puede alcanzar el puerto 22). Organizativamente, hay que adaptar las herramientas de administración/runbooks (ProxyJump, ProxyCommand).

# Beispiel: Client-Konfiguration ~/.ssh/config
Host bastion
  HostName bastion.example.net
  User admin

Host internal-*
  User admin
  ProxyJump bastion
  ServerAliveInterval 60

Riesgo: si opera el Bastion como single point of failure, intercambia un riesgo por otro. Planifique al menos redundancia (p. ej. dos Bastions, dominios de fallo separados) y un procedimiento documentado de „break-glass“.

Etapa 3: Introducir una SSH-CA para accesos de usuario

Comience con un segmento piloto. Use periodos de validez cortos (p. ej. un día laborable) y defina los principals de modo que se ajusten a sus roles. Implemente en paralelo una capacidad de revocación: si puede detener la emisión, el daño máximo de un certificado comprometido queda limitado a su periodo de validez.

Etapa 4: Representar las automatizaciones de forma ordenada (no „clave de admin para todo“)

Las automatizaciones necesitan identidades propias. Separe:

• Acceso administrativo humano (interactivo, efímero, trazable)
• Acceso de máquina (no interactivo, estrictamente limitado, idealmente también mediante lógica de certificados o claves de despliegue claramente aisladas)

Si administra Docker-Hosts por SSH (p. ej. para emergencias), defina principals/cuentas específicas para ello y evite que los sistemas CI utilicen la misma vía.

Troubleshooting: Cuando los certificados SSH o las conexiones al bastión no funcionan

En la práctica necesita pasos de comprobación rápidos que funcionen sin conocimientos especializados.

1) El certificado ha caducado o «aún no es válido»

Síntoma: el inicio de sesión falla pese a una configuración correcta. La causa suele ser la deriva del reloj. Compruebe:

# Auf Client und Zielhost: Zeit prüfen
date -u

# NTP/Chrony Status (Beispiel, distroabhängig)
chronyc tracking 2>/dev/null || true
timedatectl status

Si la hora no es correcta: primero resuelva el problema de la hora y luego pruebe de nuevo. La autenticación por certificado es implacablemente estricta en este aspecto.

2) El servidor confía en la CA equivocada (o en ninguna)

Compruebe si la clave pública de la CA está correcta y cargada:

sudo sshd -T | grep -i 'trustedusercakeys|authorizedprincipals'

# Datei vorhanden?
sudo ls -l /etc/ssh/trusted-user-ca.pub

Trampa habitual: configuración dividida mediante sshd_config.d y el orden de carga. Valide siempre con sshd -T, porque muestra la configuración efectiva.

3) El proxy del bastión se cae (red/firewall)

Si ProxyJump se queda colgado o se interrumpe, con frecuencia no es un problema de SSH sino de enrutamiento/firewall. Compruebe desde el bastión el puerto de destino:

# Auf dem Bastion-Host: Zielhost erreichbar?
TARGET=internal-host-01
nc -vz $TARGET 22

# Alternativ mit bash TCP (ohne nc)
timeout 3 bash -c "</dev/tcp/$TARGET/22" && echo OK || echo FAIL

Si eso falla, los registros SSH en el cliente ayudan poco. En ese caso la ruta de red y las Security Groups son el ámbito correcto.

Lista de comprobación: Endurecimiento de SSH en entornos empresariales (orientado a la operación)

• Red: el puerto 22 accesible solo desde el segmento de administración/bastión, no permitir excepciones directas «temporales» sin fecha de expiración.
• Auth: inicio de sesión por contraseña deshabilitado o muy RESTringido; control claro por grupos (AllowGroups).
• Bastión: reforzado, versión mínima de software, salida (outbound) RESTrictiva, registros centrales, proceso definido de Break-Glass.
• Certificados: SSH-CA introducida, tiempos de validez cortos, Principals basados en roles, tiempo/NTP estable.
• Rotación: Host-Keys/CA-Keys/User-Keys con plan, confianza paralela durante la ventana de migración, automatizaciones inventariadas.
• Auditoría: LogLevel, correlación central de logs, trazabilidad de los accesos de administración.

Estrategia de retroceso: ¿Qué hacer si la nueva autenticación bloquea el acceso?

Cualquier endurecimiento puede, en caso de error, provocar un «Self-Inflicted Outage». Por eso planifique explícitamente una estrategia de retroceso:

• Acceso fuera de banda: consola/iDRAC/IPMI/Cloud-Serial-Console — pero asegurado y probado.
• Cuenta Break-Glass: cuenta dedicada con acceso estrictamente controlado, idealmente solo a través del bastión y activa por tiempo limitado.
• Despliegue por fases: primero piloto, luego en oleadas. Nunca cambie toda la flota a la vez.
• Cambios de configuración atómicos: aplique los cambios de forma que sea posible un reload (y no un reinicio forzado en medio de un fallo).

Práctica recomendada: antes de cualquier cambio en sshd_config, mantener una segunda sesión ya abierta, comprobar sintácticamente (sshd -t) y solo entonces recargar.

# Sichere Prüfsequenz vor dem Reload
sudo sshd -t && echo "Config OK" || echo "Config ERROR"

# Erst wenn OK:
sudo systemctl reload sshd

Conclusión: el endurecimiento de SSH es realmente manejable con CA y rotación

El endurecimiento de SSH es más eficaz cuando no se limita a „endurecer sshd“, sino que se operacionaliza toda la ruta de acceso: los bastion hosts reducen la superficie de ataque y concentran la telemetría; una SSH Certificate Authority hace que las identidades sean gestionables y efímeras; la rotación de claves pasa de ser una molestia excepcional a un proceso planificado. Es crucial contemplar desde el principio la estabilidad temporal (NTP), las dependencias (automatizaciones) y una estrategia de recuperación probada. Entonces SSH no solo será más seguro, sino también más sencillo de administrar en el día a día.

Para este tema también son importantes el SSH Key Management y los certificados SSH. El artículo ordena estos aspectos de forma comprensible y muestra en qué hay que centrarse en la práctica.