Cómo proteger el acceso SSH en servidores Linux: auditoría, claves y hardening

Cómo proteger el acceso SSH en servidores Linux: auditoría y hardening práctico

El acceso SSH es una de las piezas más sensibles de cualquier servidor Linux. A través de SSH se administra el sistema, se revisan servicios, se modifican configuraciones, se despliegan aplicaciones y se resuelven incidencias técnicas. Por eso, cuando SSH está mal protegido, el riesgo no afecta solo a una cuenta de usuario: puede comprometer todo el servidor.

En muchos proyectos digitales se dedica mucha atención al diseño web, a los plugins, al rendimiento o al posicionamiento SEO, pero se descuida la capa de administración del servidor. Es un error frecuente. Un sitio web puede estar correctamente construido y, aun así, depender de un acceso remoto inseguro, con contraseña, usuario root habilitado, logs sin revisar y sin medidas automáticas contra intentos repetidos.

Proteger SSH no consiste únicamente en cambiar el puerto o instalar una herramienta. Requiere aplicar un procedimiento completo: comprobar la hora del sistema, revisar accesos exitosos, detectar intentos fallidos, identificar conexiones activas, limitar usuarios, desactivar contraseñas, usar claves seguras y activar mecanismos de bloqueo y filtrado.

En este artículo veremos cómo auditar y endurecer el acceso SSH en servidores Linux con un enfoque práctico, pensado para administración real de sistemas, servidores VPS, sitios WordPress, plataformas LMS y entornos profesionales donde la seguridad no puede depender de intuiciones.

El objetivo no es memorizar comandos aislados, sino comprender qué está ocurriendo realmente en el servidor, identificar riesgos y tomar decisiones técnicas con criterio.

Índice

• Por qué el acceso SSH es crítico en un servidor Linux
• Comprobar la hora del sistema antes de auditar
• Auditoría de accesos SSH exitosos
• Cómo obtener una salida limpia de accesos SSH
• Cómo excluir IPs de confianza para detectar accesos sospechosos
• Cómo revisar intentos fallidos de acceso SSH
• Cómo revisar conexiones SSH abiertas por fecha
• Monitorización SSH en tiempo real
• Hardening SSH: medidas esenciales de endurecimiento
• Uso de claves ed25519 para autenticación SSH segura
• Alternativa: contraseña robusta y política de rotación
• Cambio de puerto SSH: utilidad real y límites
• Cómo limitar usuarios permitidos
• Firewall, Fail2ban y limitación de conexiones
• Revisión operativa y rutina de seguridad SSH
• Errores comunes al proteger SSH
• Por qué aprender administración segura de Linux
• Preguntas frecuentes sobre seguridad SSH
• Conclusión

Por qué el acceso SSH es crítico en un servidor Linux

SSH, o Secure Shell, es el protocolo más utilizado para administrar servidores Linux de forma remota. Permite acceder a una consola del sistema desde otro equipo y ejecutar tareas de administración sin necesidad de estar físicamente delante del servidor.

Esto lo convierte en una herramienta imprescindible, pero también en una superficie de ataque muy importante. Si una persona no autorizada consigue acceso SSH, puede revisar archivos, modificar configuraciones, instalar software, crear usuarios, detener servicios o escalar privilegios si la configuración del sistema lo permite.

Los riesgos más habituales asociados a una mala configuración SSH son:

• ataques de fuerza bruta contra usuarios y contraseñas;
• intentos automáticos contra la cuenta root;
• uso de contraseñas débiles, antiguas o reutilizadas;
• usuarios con acceso que ya no deberían conservarlo;
• ausencia de firewall o reglas de filtrado;
• falta de revisión periódica de los logs de autenticación;
• servicios expuestos directamente a Internet sin bloqueo automático;
• desconocimiento de qué IPs acceden realmente al servidor.

La seguridad SSH debe entenderse como una combinación de auditoría, configuración y vigilancia. No basta con aplicar una medida aislada. Lo correcto es construir varias capas de protección que reduzcan la probabilidad de acceso no autorizado y faciliten detectar comportamientos anómalos.

Este enfoque es especialmente importante en servidores que alojan sitios web, tiendas online, campus virtuales, plataformas LMS o proyectos empresariales. En esos casos, la seguridad del servidor forma parte directa de la continuidad operativa.

Comprobar la hora del sistema antes de auditar

Antes de revisar logs, conviene verificar la hora del sistema. Puede parecer una comprobación secundaria, pero una auditoría depende de marcas de tiempo fiables. Si la hora del servidor no es correcta, los eventos pueden interpretarse mal.

Para ver la fecha y hora actual del sistema:

date

Para ver solo la hora:

date +%T

Esta verificación resulta útil cuando se investigan accesos recientes, intentos fallidos, reinicios inesperados o actividad sospechosa en una franja concreta. Si los timestamps no son fiables, una revisión puede llevar a conclusiones equivocadas.

En servidores profesionales también conviene mantener sincronización horaria correcta mediante NTP o servicios equivalentes del sistema. La hora del servidor no afecta solo a SSH: influye en logs, copias de seguridad, certificados, tareas programadas y correlación de eventos.

Auditoría de accesos SSH exitosos

Una auditoría básica de SSH debe empezar por una pregunta muy concreta: quién ha entrado realmente en el servidor, desde qué dirección IP y mediante qué método de autenticación.

En sistemas basados en Debian o Ubuntu, los accesos SSH suelen registrarse en /var/log/auth.log y en sus archivos rotados. Para revisar accesos exitosos reales por SSH, puede utilizarse el siguiente comando:

sudo zgrep -h -E "sshd.*Accepted (password|publickey) for" /var/log/auth.log*

Este filtrado captura líneas en las que el servicio SSH ha aceptado autenticación por contraseña o clave pública. Es decir, se centra en accesos reales y evita parte del ruido del log.

El resultado puede mostrar entradas similares a estas:

sshd[...] Accepted password for usuario from IP port puerto
sshd[...] Accepted publickey for usuario from IP port puerto

Durante la revisión conviene fijarse en:

• usuarios que han accedido;
• IPs de origen;
• horas de acceso;
• método de autenticación utilizado;
• repetición de accesos desde ubicaciones no habituales;
• accesos posteriores a muchos intentos fallidos.

Este análisis resulta especialmente útil para identificar actividad no esperada, cuentas olvidadas o conexiones que no encajan con el patrón habitual de administración.

Cómo obtener una salida limpia de accesos SSH

Los logs completos contienen mucha información. Para revisiones rápidas suele ser útil extraer solo los campos más relevantes, como fecha, usuario e IP.

Una forma sencilla es:

sudo zgrep -h -E "sshd.*Accepted (password|publickey) for" /var/log/auth.log* \
| awk '{print $1, $9, $11}'

Esta salida resumida facilita comparar accesos, revisar actividad de días concretos y detectar comportamientos anómalos sin leer logs extensos línea por línea.

Cómo excluir IPs de confianza para detectar accesos sospechosos

En muchos servidores existen direcciones IP habituales desde las que se administra el sistema. Una forma práctica de detectar actividad no esperada consiste en excluir esas IPs de confianza.

sudo zgrep -h -E "sshd.*Accepted (password|publickey) for" /var/log/auth.log* \
| grep -v "direccion_ip_habitual_1" \
| grep -v "direccion_ip_habitual_2" \
| grep -v "direccion_ip_habitual_3"

Esto ayuda a centrar la atención en conexiones menos habituales y reduce ruido durante una auditoría manual.

Cómo revisar intentos fallidos de acceso SSH

Los intentos fallidos de SSH son una señal importante. En servidores expuestos a Internet es normal recibir intentos automáticos de acceso, pero eso no significa que deban ignorarse.

Muchos bots automatizados recorren Internet intentando acceder mediante combinaciones conocidas de usuario y contraseña. En entornos reales es frecuente encontrar intentos sobre cuentas como root, admin, ubuntu, test o nombres de usuarios genéricos.

Por eso, revisar intentos fallidos no consiste únicamente en mirar si “hay errores”, sino en entender el comportamiento del servidor: frecuencia, intensidad, horarios y patrones.

Para revisar intentos fallidos por hora durante el día actual:

sudo zgrep -h "Failed password" /var/log/auth.log* \
| grep "$(date +%Y-%m-%d)" \
| awk '{hora=substr($1,12,2); c[hora]++} END {for(h in c) print h, c[h]}' \
| sort -n

Este comando permite agrupar intentos fallidos por hora y detectar si existe un pico de actividad anormal.

Por ejemplo, si normalmente el servidor recibe pocos intentos y de repente aparecen cientos de intentos concentrados entre las 03:00 y las 04:00, puede existir una campaña automatizada contra el acceso SSH.

Para ver el listado cronológico completo de intentos fallidos del día:

sudo zgrep -h "Failed password" /var/log/auth.log* \
| grep "$(date +%Y-%m-%d)" \
| sort

Durante la revisión conviene observar varios elementos:

• IPs que repiten intentos muchas veces;
• usuarios inexistentes probados automáticamente;
• intentos contra root;
• actividad concentrada en pocos minutos;
• intentos desde redes o países inesperados;
• relación entre intentos fallidos y accesos exitosos posteriores.

Un intento fallido aislado no implica una intrusión. Sin embargo, muchos intentos repetidos, especialmente cuando el servidor permite autenticación por contraseña, indican una exposición que conviene reducir.

En estos casos resulta especialmente recomendable complementar la revisión manual con herramientas de bloqueo automático como Fail2ban y limitar la exposición mediante firewall.

Cómo revisar conexiones SSH abiertas por fecha

Además de revisar todos los accesos históricos, puede resultar útil separar la actividad por fechas. Esto ayuda a comparar comportamientos entre días, localizar accesos concretos o investigar incidencias.

Por ejemplo, si se ha producido una modificación inesperada del sistema, una caída de servicio o un cambio no documentado, puede ser interesante comprobar quién accedió al servidor ese día.

Para revisar conexiones SSH aceptadas durante el día actual:

sudo zgrep -h -E "sshd.*Accepted (password|publickey) for" /var/log/auth.log* \
| grep "$(date +%Y-%m-%d)"

Para revisar conexiones aceptadas ayer:

sudo zgrep -h -E "sshd.*Accepted (password|publickey) for" /var/log/auth.log* \
| grep "$(date -d yesterday +%Y-%m-%d)"

Esta técnica permite construir una rutina operativa sencilla: revisar diariamente accesos recientes y confirmar que todos corresponden a actividad esperada.

También resulta útil para detectar accesos fuera del horario habitual, conexiones desde ubicaciones nuevas o actividad técnica que nadie recuerda haber realizado.

Monitorización SSH en tiempo real

Los logs muestran lo que ya ha ocurrido. Sin embargo, en ocasiones interesa comprobar qué está pasando exactamente en este momento.

Esto puede resultar útil cuando existe sospecha de actividad no autorizada, se está realizando un diagnóstico o simplemente se quiere confirmar quién está conectado al servidor.

Para revisar conexiones SSH activas relacionadas con el puerto 22:

sudo ss -tnp | grep ":22 "

Este comando muestra conexiones TCP activas y, cuando es posible, información sobre el proceso implicado. Permite identificar sesiones abiertas y verificar direcciones IP conectadas.

Para monitorizar tráfico SSH en tiempo real:

sudo tcpdump -n port 22

tcpdump es una herramienta potente y conviene usarla con criterio. En producción suele ser preferible limitar el alcance de las capturas y evitar registrar más datos de los estrictamente necesarios.

La monitorización en tiempo real tiene sentido cuando existe una hipótesis concreta o una incidencia. Para vigilancia permanente suelen ser más apropiados los logs, las alertas automáticas, el firewall, Fail2ban y sistemas centralizados de monitorización.

Hardening SSH: medidas esenciales de endurecimiento

El hardening SSH consiste en reducir la superficie de ataque del servicio y limitar las posibilidades de acceso no autorizado.

No se trata de ejecutar comandos de memoria, sino de entender qué riesgo reduce cada medida y cómo se complementan unas con otras.

Las medidas más importantes incluyen:

• desactivar el acceso SSH directo como root;
• desactivar la autenticación por contraseña;
• usar claves públicas seguras;
• limitar usuarios autorizados;
• apoyarse en firewall y Fail2ban;
• limitar conexiones repetidas;
• revisar logs periódicamente;
• mantener OpenSSH actualizado.

La configuración principal suele encontrarse en:

/etc/ssh/sshd_config

Antes de modificar el archivo de configuración conviene mantener una sesión SSH abierta de respaldo y validar la sintaxis:

sudo sshd -t

Si no aparecen errores, puede reiniciarse el servicio:

sudo systemctl restart ssh

En algunas distribuciones el servicio puede llamarse:

sudo systemctl restart sshd

Comprobar antes de reiniciar no es paranoia técnica: es una medida básica para evitar quedarse fuera del servidor tras un error de configuración.

Desactivar el acceso SSH directo como root

La cuenta root dispone de privilegios máximos. Permitir acceso directo mediante SSH convierte a esta cuenta en un objetivo prioritario para ataques automatizados.

Para impedir el login directo como root:

PermitRootLogin no

Esto no elimina la administración avanzada del sistema. La práctica recomendada consiste en acceder con un usuario autorizado y elevar privilegios mediante sudo cuando sea necesario.

Este enfoque mejora trazabilidad, reduce exposición y evita que todos los intentos automáticos se concentren sobre la cuenta más sensible del servidor.

Desactivar la autenticación por contraseña

Las contraseñas son uno de los puntos débiles más habituales en SSH. Pueden ser débiles, reutilizadas, filtradas o atacadas mediante fuerza bruta.

Cuando el acceso mediante clave pública ya está configurado y probado, resulta muy recomendable desactivar la autenticación por contraseña:

PasswordAuthentication no

Antes de aplicar esta medida hay que comprobar cuidadosamente que el acceso por clave funciona. De lo contrario, podría perderse acceso remoto al servidor.

Eliminar autenticación por contraseña reduce drásticamente la utilidad de ataques automatizados.

Uso de claves ed25519 para autenticación SSH segura

La autenticación mediante claves públicas es una de las medidas más eficaces para proteger SSH. Entre las opciones actuales, ed25519 representa una alternativa moderna, eficiente y segura.

Estas claves son pequeñas, rápidas, seguras y resistentes frente a ataques avanzados, incluyendo determinados ataques de timing.

Para generar una clave:

ssh-keygen -t ed25519 -a 100

Para instalarla en el servidor:

ssh-copy-id -i ~/.ssh/id_ed25519 usuario@servidor

Tras copiar la clave, conviene probar el acceso:

ssh usuario@servidor

La clave privada debe protegerse adecuadamente y no copiarse sin control entre dispositivos inseguros.

Alternativa: contraseña robusta y política de rotación

No todos los entornos utilizan autenticación mediante claves públicas desde el primer momento. En algunos escenarios pequeños, laboratorios, servidores domésticos, proyectos personales o infraestructuras temporales puede optarse inicialmente por una política basada en contraseñas robustas.

Ahora bien, esto no significa utilizar “una contraseña cualquiera”. Si se mantiene autenticación por contraseña, debe existir una política clara y disciplinada.

En este enfoque conviene aplicar varias medidas:

• Usar contraseñas largas y robustas, evitando palabras comunes, fechas, nombres propios o patrones previsibles.
• Combinar mayúsculas, minúsculas, números y caracteres especiales.
• No reutilizar contraseñas empleadas en otros servicios o sistemas.
• Aplicar una política de rotación periódica, por ejemplo cambiando la contraseña cada 15 días.
• Evitar compartir credenciales entre varios usuarios.
• Utilizar gestores de contraseñas para reducir el riesgo de claves débiles o memorizadas de forma insegura.

Un ejemplo de política razonable podría ser utilizar frases largas, difíciles de adivinar, generadas aleatoriamente y renovadas periódicamente según criticidad del sistema.

Sin embargo, conviene entender una diferencia técnica importante: una contraseña robusta bien gestionada puede mejorar mucho la seguridad, pero sigue ofreciendo menos protección que una autenticación basada en claves públicas correctamente configuradas.

Las claves públicas eliminan gran parte de la exposición frente a ataques de fuerza bruta, reducen el riesgo derivado de filtraciones y permiten endurecer más fácilmente el acceso remoto.

Por ello, una estrategia pragmática en algunos entornos consiste en empezar con una política fuerte de contraseñas y evolucionar posteriormente hacia autenticación mediante claves públicas ed25519 cuando la infraestructura, criticidad o madurez operativa del sistema lo justifique.

Si se mantiene autenticación por contraseña, cobra todavía más importancia complementar el acceso SSH con medidas como Fail2ban, limitación de conexiones, firewall, auditoría periódica y revisión de logs.

Cambio de puerto SSH: utilidad real y límites

El puerto estándar de SSH es el 22. Cambiarlo puede reducir ruido en los logs y evitar parte de los escaneos automáticos más básicos, aunque conviene entender correctamente qué aporta y qué no aporta.

La idea práctica consiste en modificar el puerto expuesto públicamente para que no sea el puerto estándar.

• Qué cambiar: el puerto SSH visible desde Internet para que no sea el 22.
• Ejemplo: usar un puerto alternativo como 2222.
• Dónde cambiarlo: preferiblemente no en el servidor, sino en la redirección del router o firewall perimetral.
• Cuándo cambiarlo: realizar rotaciones periódicas del puerto expuesto para reducir repetición de escaneos automatizados.

Por ejemplo, puede mantenerse el servicio SSH escuchando internamente en el puerto 22 y configurar el router para que el puerto externo 2222 redirija internamente hacia el puerto 22 del servidor.

Este enfoque tiene una ventaja operativa importante: permite modificar el puerto público sin tocar continuamente el archivo de configuración SSH del servidor.

Además, si se decide rotar el puerto expuesto, basta con modificar la regla de redirección de red en el router o firewall sin necesidad de editar constantemente el servicio SSH.

Esta estrategia resulta especialmente práctica en pequeños entornos empresariales, laboratorios, oficinas técnicas o infraestructuras domésticas avanzadas donde el servidor está detrás de un router.

Aun así, conviene no engañarse: cambiar el puerto reduce ruido, pero no sustituye a claves SSH, contraseñas robustas, firewall, Fail2ban, limitación de conexiones y revisión de logs.

Cómo limitar usuarios permitidos por SSH

No todos los usuarios del sistema necesitan acceso SSH. Limitar explícitamente qué cuentas pueden conectarse reduce la superficie de ataque y evita accesos innecesarios.

Puede restringirse el acceso únicamente a determinados usuarios:

AllowUsers usuario1 usuario2

Esto permite que solo las cuentas indicadas puedan autenticarse mediante SSH, aunque existan otros usuarios en el sistema.

La medida resulta especialmente útil cuando existen cuentas de servicio, usuarios históricos, perfiles temporales o aplicaciones que no necesitan acceso remoto interactivo.

La revisión periódica de usuarios autorizados debe formar parte del mantenimiento básico del servidor. Un usuario olvidado puede convertirse en una puerta de entrada involuntaria.

Firewall, Fail2ban y limitación de conexiones

La protección de SSH mejora mucho cuando se combina configuración del servicio con controles de red y bloqueo automático.

Dos herramientas habituales en entornos Linux son UFW y Fail2ban.

Activar firewall UFW

Para permitir SSH mediante UFW:

sudo ufw allow 22/tcp

Para activar el firewall:

sudo ufw enable

Si se utiliza un puerto alternativo:

sudo ufw allow 2222/tcp

Antes de activar el firewall conviene revisar cuidadosamente las reglas. Un error puede bloquear el acceso remoto legítimo.

Limitar conexiones repetidas

UFW permite reducir la velocidad de intentos repetidos:

sudo ufw limit 22/tcp

Esta medida no sustituye otras protecciones, pero añade una capa útil frente a ciertos ataques repetitivos.

Activar Fail2ban

Fail2ban revisa logs y bloquea automáticamente IPs que generan demasiados intentos fallidos.

Su función es sencilla: si una dirección IP insiste demasiadas veces, se bloquea durante un tiempo determinado.

Esto ayuda a reducir ataques automatizados, disminuir ruido en logs y limitar exposición innecesaria.

Sin embargo, Fail2ban no sustituye una buena configuración SSH. Lo recomendable es combinarlo con autenticación fuerte, control de usuarios, firewall, revisión de logs y políticas razonables de acceso.

Revisión operativa y rutina de seguridad SSH

La seguridad SSH no termina cuando el servidor queda configurado. Los sistemas evolucionan, los usuarios cambian, las IPs cambian y los riesgos también.

Por ello conviene establecer una rutina operativa mínima.

• revisar accesos SSH recientes;
• comprobar intentos fallidos;
• identificar IPs desconocidas;
• revisar conexiones activas;
• verificar reglas de firewall;
• confirmar funcionamiento de Fail2ban;
• documentar IPs habituales;
• mantener OpenSSH actualizado;
• registrar cambios importantes realizados en el sistema.

La seguridad real no consiste en evitar todos los eventos sospechosos, sino en detectarlos y reaccionar antes de que se conviertan en un problema.

Errores comunes al proteger SSH

Muchos problemas aparecen por configuraciones incompletas o mal entendidas.

• confiar únicamente en cambiar el puerto;
• dejar activo el acceso root;
• mantener contraseñas débiles;
• no probar las claves antes de desactivar contraseñas;
• no revisar logs durante meses;
• activar firewall sin validar reglas;
• no revisar usuarios autorizados;
• instalar Fail2ban y asumir que ya está “todo resuelto”.

Administrar servidores exige método. Hay que saber qué se cambia, cómo comprobarlo y cómo revertirlo si algo sale mal.

Por qué aprender administración segura de Linux

Proteger SSH es una competencia concreta dentro de un área mucho más amplia: la administración segura de sistemas Linux.

No basta con saber conectarse a un servidor o copiar comandos encontrados en Internet. La administración real exige comprender qué ocurre en el sistema, interpretar logs, gestionar permisos, controlar usuarios, mantener servicios y saber reaccionar cuando algo falla.

Este conocimiento resulta especialmente útil para:

• administradores de sistemas;
• responsables de servidores VPS;
• profesionales que mantienen sitios WordPress;
• técnicos que gestionan plataformas LMS;
• desarrolladores que despliegan aplicaciones;
• pequeñas empresas con infraestructura propia;
• personas que quieren reducir dependencia técnica y ganar autonomía.

Una formación online bien estructurada permite avanzar de forma progresiva: primero comprendiendo conceptos, después ejecutando procedimientos, interpretando resultados y finalmente tomando decisiones con criterio.

La diferencia entre “saber usar Linux” y “administrar Linux” suele estar precisamente ahí: en la capacidad de entender qué significa cada log, qué impacto tiene un cambio de configuración y cómo minimizar riesgos.

Además, proteger SSH conecta con muchas otras áreas de seguridad e infraestructura: continuidad operativa, copias de seguridad, protección de datos, endurecimiento de servicios y diseño de sistemas resilientes.

Por ello, esta temática puede complementarse con contenidos relacionados como cómo evitar la pérdida de datos, cómo proteger archivos sensibles o diseño de sistemas robustos.

Aprender seguridad SSH no consiste únicamente en proteger un puerto. Consiste en desarrollar una forma de trabajar más profesional, metódica y menos dependiente de improvisaciones.

Preguntas frecuentes sobre seguridad SSH

Conclusión

El acceso SSH no debe tratarse como un simple detalle técnico. Es una de las puertas principales de administración de un servidor Linux y, por tanto, una pieza crítica de seguridad.

Una estrategia razonable combina auditoría y endurecimiento: revisar accesos exitosos, analizar intentos fallidos, comprobar conexiones activas, limitar usuarios, controlar contraseñas, usar claves públicas cuando sea posible, configurar firewall, apoyarse en Fail2ban y mantener hábitos de revisión periódica.

La seguridad real no aparece por casualidad ni depende de un único comando milagroso. Se construye mediante decisiones acumulativas, pequeñas medidas coherentes y una forma de trabajo basada en criterio técnico.

La diferencia entre un servidor aparentemente seguro y un servidor realmente gestionado suele estar en la disciplina operativa.

Para quienes administran servidores Linux, sitios WordPress, VPS, plataformas LMS o infraestructura empresarial ligera, comprender SSH y aprender a protegerlo representa una inversión directa en continuidad operativa, autonomía técnica y reducción de riesgos.

En tecnología, proteger bien un sistema suele ser menos costoso que recuperarlo después de un problema.