SSH suele ser la puerta de administración más poderosa de un servidor. Protegerla implica controlar qué cuentas pueden entrar, desde dónde, con qué método de autenticación y qué acciones pueden realizar después. Cambiar un número de puerto puede reducir ruido automatizado, pero no sustituye esas decisiones.
El objetivo es que una sesión legítima sea identificable y revocable, y que una credencial comprometida no entregue más privilegios de los necesarios.
Empieza por las cuentas
Usa identidades individuales y evita compartir una cuenta administrativa. El registro debe permitir relacionar una sesión con una persona o servicio. Desactiva cuentas antiguas y revisa qué usuarios pertenecen a grupos con capacidad de usar sudo.
Limitar el acceso directo de root facilita atribuir cambios y reduce el impacto de un error. Una cuenta administradora puede elevar privilegios para una tarea concreta, mientras las operaciones rutinarias se ejecutan con menos alcance.
Política de autenticación
Las claves públicas suelen facilitar la revocación individual y la automatización controlada. Las contraseñas pueden mantenerse como recuperación bajo condiciones estrictas, pero deben ser únicas, robustas y protegidas contra intentos repetidos. El método elegido debe tener un procedimiento claro para pérdida o sospecha de compromiso.
Protege las claves privadas en el dispositivo cliente y verifica las claves de host para no administrar un destino equivocado. Un canal cifrado no prueba por sí solo la identidad del servidor ni la legitimidad del usuario.
Reducir la exposición de red
Si es posible, restringe SSH a una red de administración, VPN o lista de orígenes mantenida. Un firewall de host puede limitar el puerto, y un control aguas arriba puede reducir el tráfico antes de que llegue al sistema. Revisa también IPv4 e IPv6 para no dejar una ruta olvidada.
Desplazar SSH a otro puerto no oculta el servicio de un análisis serio ni corrige credenciales débiles. Puede reducir intentos triviales, pero la autenticación y los límites siguen siendo necesarios.
Privilegios después del inicio de sesión
Configura sudo con permisos acordes a las tareas y evita que un usuario pueda ejecutar cualquier comando privilegiado sin control. Las cuentas de despliegue deberían poder modificar solo rutas concretas y no leer secretos que no necesitan. Los permisos de archivos y la separación de procesos completan esta frontera.
Un script automatizado merece la misma revisión que una persona: identidad separada, clave con alcance limitado, destino permitido y logs. No incrustes claves en repositorios ni en scripts compartidos.
Registros y señales
Revisa inicios de sesión, fallos, cambios de configuración, uso de sudo y nuevas claves autorizadas. Correlaciona hora, origen y cuenta. Un bloqueo automático puede ayudar, pero debe distinguir una incidencia legítima de un ataque distribuido y no dejar al equipo sin acceso de recuperación.
Actualizaciones y mantenimiento
Mantén actualizado el servidor SSH y el sistema, prueba cambios en una ventana controlada y conserva una vía de acceso alternativa verificada. Después de una migración comprueba que los usuarios y claves esperados siguen presentes y que no se arrastraron entradas antiguas.
Qué revisar periódicamente después de endurecer el acceso
Revisa cuentas, claves, grupos, reglas de red, versiones y registros con una periodicidad definida. Simula la revocación de una clave y comprueba que una cuenta retirada ya no puede entrar. SSH puede ofrecer un canal robusto, pero el resultado depende de la identidad, los permisos, el equipo cliente y la operación completa.
Separar acceso humano y automatizado
Una cuenta de despliegue, una cuenta de monitorización y una cuenta de administración tienen necesidades distintas. Asignarles identidades separadas permite limitar comandos, revocar una integración y revisar qué proceso realizó un cambio. No incrustes claves en repositorios, imágenes o scripts compartidos.
Las reglas de sudo deben indicar qué operaciones necesita cada rol. Dar acceso completo para evitar errores de permisos puede convertir una tarea rutinaria en una escalada permanente.
Comprobar una configuración remota
Antes de cerrar una sesión existente, abre una segunda sesión de prueba con el método que se conservará. Verifica que la configuración se recarga sin errores y que existe una ruta de recuperación documentada. Una restricción correcta aplicada sin plan de retorno puede producir una interrupción administrativa.
Después de una migración revisa usuarios, claves, grupos, reglas de firewall, logs y dirección de escucha. También comprueba IPv6 y los accesos desde automatizaciones antiguas.
Acceso de emergencia y cambios auditables
El acceso de recuperación debe probarse sin esperar a una caída. Mantén credenciales o consola alternativas bajo control, registra su uso y revisa que no dependan del mismo proveedor o red que el acceso habitual. Después de una emergencia, rota los secretos utilizados.
Versiona la configuración de SSH y revisa cambios con otra persona cuando afecten a todos los administradores. Un cambio pequeño en grupos, rutas o algoritmos admitidos puede dejar fuera a una automatización o abrir una excepción inesperada.
Revisar el acceso como proceso continuo
Una revisión trimestral o ligada a cambios del equipo puede localizar usuarios, claves y reglas que ya no tienen una razón válida. Comprueba también que los registros llegan a un lugar que el propio servidor no pueda borrar fácilmente. La configuración de SSH debe acompañar a la gestión de identidades, actualizaciones y recuperación. Documenta quién revisa cada excepción y cuándo caduca.