Cómo asegurar SSH en Linux: guía práctica para proteger el acceso a tu servidor

Introducción

SSH es una de las herramientas más útiles y más importantes en Linux. Gracias a él puedes conectarte de forma remota a un servidor, una Raspberry Pi, un VPS o cualquier sistema Linux accesible por red. Es cómodo, potente y esencial para administración real.

Pero precisamente por eso también es uno de los objetivos favoritos de bots, escáneres automáticos y ataques de fuerza bruta.

Si tienes un servidor expuesto a internet con SSH activo, puedes dar por hecho que tarde o temprano recibirá intentos de acceso. No hace falta que el proyecto sea famoso ni que tengas datos ultra sensibles. Los escaneos llegan solos.

Por eso conviene asegurar SSH desde el principio.

Asegurar SSH no significa volverlo inaccesible ni hacer configuraciones absurdamente complejas. Significa aplicar medidas razonables para reducir riesgos, mejorar el control y evitar errores típicos.

En esta guía vamos a ver cómo proteger SSH en Linux con una estrategia práctica: desde las claves SSH y la desactivación de contraseñas hasta cambios de configuración, limitación de acceso, firewall y buenas prácticas que de verdad aportan valor.

Por qué es importante proteger SSH

Porque SSH es una puerta de entrada administrativa al sistema.

Si alguien consigue acceso por SSH, el nivel de impacto puede ser enorme:

• ver archivos
• modificar configuraciones
• desplegar malware
• robar datos
• pivotar a otros servicios
• manipular aplicaciones
• usar el servidor para otros fines

Eso significa que no conviene dejar el acceso SSH “tal cual viene” si el sistema está públicamente expuesto.

Incluso en entornos pequeños o personales, una configuración más segura marca una gran diferencia.

Riesgos comunes de un SSH mal protegido

Algunos problemas frecuentes son:

• permitir acceso por contraseña débil
• mantener al usuario root accesible directamente
• dejar SSH en el puerto por defecto sin ninguna otra capa
• no limitar intentos o accesos
• no usar claves SSH
• no revisar logs
• dejar el servicio expuesto desde cualquier lugar sin necesidad

No todos estos puntos tienen la misma gravedad en todos los entornos, pero cuantos más acumules, peor.

Primer gran paso: usar claves SSH en lugar de contraseña

Si hay una medida que realmente sube mucho el nivel de seguridad, es esta:

usar claves SSH en lugar de autenticación por contraseña.

La idea es simple:

• tu equipo tiene una clave privada
• el servidor guarda tu clave pública
• cuando te conectas, el servidor verifica que posees la clave privada correcta

Ventajas:

• mucho más difícil de atacar por fuerza bruta que una contraseña simple
• más cómodo en el día a día
• estándar en entornos profesionales
• permite luego desactivar el acceso por contraseña

Esto es una de las mejores decisiones que puedes tomar con SSH.

Qué es una clave pública y qué es una clave privada

La clave privada se queda en tu equipo y no debes compartirla.

La clave pública es la que copias al servidor para autorizar el acceso.

Piensa en ello así:

• la clave pública es como una cerradura especial que colocas
• la clave privada es la llave real que solo tú tienes

Si alguien obtiene tu clave privada, ahí sí tienes un problema serio. Por eso hay que protegerla bien.

Cómo generar una clave SSH

En tu equipo local puedes generar un par de claves con:

ssh-keygen

Esto suele pedirte:

• ruta de guardado
• passphrase opcional

Si quieres reforzar todavía más la seguridad, puedes usar passphrase en la clave privada. Así, aunque alguien copie tu clave, seguirá necesitando esa frase adicional.

Cómo copiar tu clave pública al servidor

Una forma muy habitual es usar:

ssh-copy-id usuario@ip-del-servidor

Esto instala tu clave pública en la cuenta remota para que el servidor la reconozca.

Después de eso, ya podrás autenticarte con clave, siempre que la configuración del servidor lo permita.

Comprobar que el acceso con clave funciona antes de tocar nada

Este punto es crítico.

Antes de desactivar contraseñas o endurecer SSH, asegúrate de que puedes entrar bien con la clave.

Haz pruebas reales:

• abre otra terminal
• conéctate por SSH
• verifica que accedes correctamente
• confirma que no dependes todavía de la contraseña

No hagas cambios importantes a ciegas, porque podrías dejarte fuera.

Desactivar autenticación por contraseña

Una vez que el acceso con clave funciona bien, una medida muy recomendable es desactivar la autenticación por contraseña.

Esto reduce muchísimo el riesgo frente a ataques automáticos de fuerza bruta.

La configuración suele estar en el archivo del servicio SSH, normalmente algo como:

/etc/ssh/sshd_config

Ahí puedes revisar o ajustar directivas relacionadas con autenticación por contraseña.

El objetivo sería dejar deshabilitado el login por contraseña una vez confirmado que las claves funcionan.

⚠️ Muy importante: haz esto solo cuando estés seguro de que el acceso por clave ya está operativo.

Evitar el acceso directo como root

Otra recomendación muy habitual es no permitir login SSH directo como root.

¿Por qué?

Porque el usuario root es conocido, poderoso y suele ser el primer objetivo de muchos intentos automáticos.

Es más seguro:

• usar un usuario normal o administrativo
• conectarte con ese usuario
• y elevar privilegios con sudo cuando haga falta

Esto reduce exposición y deja mejor trazabilidad de acciones.

Cambiar el puerto SSH: útil, pero no mágico

Mucha gente oye que cambiar SSH del puerto 22 a otro puerto “soluciona” la seguridad. No es así.

Cambiar el puerto no reemplaza medidas importantes como:

• usar claves SSH
• desactivar contraseñas
• limitar accesos
• revisar logs
• usar firewall o fail2ban

Pero sí puede ayudar a:

• reducir ruido de bots básicos
• disminuir intentos automáticos más simples
• limpiar algo el nivel de escaneo genérico

Es una medida secundaria, no la principal.

Si decides cambiarlo, recuerda:

• actualizar el firewall
• probar acceso en el nuevo puerto
• no cerrar el anterior hasta haber verificado el nuevo
• documentarlo bien

Limitar acceso por IP con firewall

Si siempre te conectas desde una IP fija o desde un rango conocido, una medida muy potente es permitir SSH solo desde ahí.

Por ejemplo con UFW podrías hacer algo como:

sudo ufw allow from 203.0.113.10 to any port 22 proto tcp

O al puerto personalizado que uses.

Esto significa que aunque SSH esté activo, solo ciertas IPs pueden intentar entrar.

No siempre es viable si viajas mucho o tu IP cambia constantemente, pero si puedes hacerlo, mejora mucho la seguridad.

Cómo revisar el estado del servicio SSH

Puedes comprobar si el servicio está funcionando con:

systemctl status ssh

O en algunas distribuciones:

systemctl status sshd

Esto te ayuda a:

• verificar que está activo
• detectar errores
• confirmar reinicios
• ver información reciente

Reiniciar SSH después de cambios

Cuando cambias configuración de SSH, normalmente tendrás que recargar o reiniciar el servicio.

Ejemplo:

sudo systemctl restart ssh

o según la distribución:

sudo systemctl restart sshd

⚠️ Haz esto con mucho cuidado si estás conectado remotamente.

Lo ideal es:

• tener otra sesión abierta
• probar el nuevo acceso antes de cerrar la sesión actual

Eso te da margen si algo sale mal.

Revisar logs de SSH

Una parte muy útil de asegurar SSH es mirar qué está pasando realmente.

Puedes revisar logs con herramientas como:

journalctl -u ssh

o archivos de autenticación según tu distribución.

Esto te ayuda a ver:

• intentos fallidos
• accesos correctos
• usuarios equivocados
• errores de clave
• problemas de permisos
• actividad sospechosa

Mirar logs de SSH te enseña muchísimo sobre cómo está siendo atacado o usado tu sistema.

Configuraciones comunes para endurecer SSH

Aunque los nombres exactos de las directivas pueden variar según el sistema y conviene revisarlas con cuidado en tu archivo de configuración, las ideas principales suelen ser estas:

• desactivar login directo de root
• desactivar autenticación por contraseña
• permitir solo autenticación por clave
• limitar usuarios autorizados si hace falta
• cambiar puerto si tiene sentido
• endurecer tiempos o intentos según el caso

Lo importante no es copiar bloques a ciegas, sino entender qué hace cada decisión.

Ejemplo de estrategia práctica y razonable

Si me preguntas por un endurecimiento básico y sensato para un VPS Linux expuesto, yo pensaría en algo como esto:

1. generar clave SSH
2. copiar clave pública al servidor
3. confirmar que el login por clave funciona
4. crear o usar un usuario con sudo
5. desactivar acceso directo como root
6. desactivar contraseñas
7. ajustar firewall para permitir solo SSH necesario
8. revisar logs
9. complementar con fail2ban

Esto ya sube muchísimo el nivel de seguridad sin volverte loco.

Qué hacer si usas un puerto SSH personalizado

Si cambias el puerto, recuerda actualizar UFW antes de reiniciar el servicio.

Por ejemplo, si decides usar 2222:

sudo ufw allow 2222/tcp

Y luego, cuando compruebes que funciona correctamente, podrías dejar de permitir el 22 si ya no lo necesitas.

Pero hazlo en este orden:

1. abre el nuevo puerto
2. reinicia SSH
3. prueba acceso por el nuevo puerto
4. solo después considera cerrar el anterior

Cómo conectarte a SSH en puerto personalizado

Ejemplo:

ssh -p 2222 usuario@ip-del-servidor

Este detalle parece obvio, pero mucha gente cambia el puerto y luego olvida especificarlo al conectarse.

Errores comunes al asegurar SSH

1. Desactivar contraseñas sin haber probado claves

Error clásico y peligroso.

2. Reiniciar SSH sin revisar configuración

Si hay un error, puedes perder acceso remoto.

3. Cambiar puerto y olvidar el firewall

Entonces el nuevo acceso no entra.

4. Seguir usando root directamente

No es lo ideal para administración diaria.

5. Pensar que cambiar el puerto ya basta

No. Ayuda algo, pero no sustituye las medidas importantes.

6. No revisar logs nunca

Pierdes visibilidad de intentos de acceso y fallos.

Buenas prácticas con SSH seguro

• usa claves SSH
• protege tu clave privada
• prueba acceso por clave antes de desactivar contraseñas
• evita login directo de root
• aplica firewall
• cambia el puerto solo si lo entiendes como capa adicional, no como solución mágica
• revisa logs con frecuencia
• usa fail2ban si el servidor está expuesto
• mantén el sistema actualizado

Conclusión:

Asegurar SSH en Linux es una de las mejores inversiones que puedes hacer si administras cualquier sistema remoto. No hace falta montar una configuración imposible ni convertir el servidor en una fortaleza inusable. Basta con aplicar medidas coherentes, en el orden correcto, y entender bien qué estás protegiendo.

Las claves SSH, la desactivación de contraseñas, evitar el login directo como root, revisar logs y controlar acceso con firewall son medidas que realmente hacen diferencia.

Si SSH es la puerta de entrada a tu servidor, merece la pena reforzar esa puerta bien desde el principio.