Configurar acceso remoto seguro a servidores Linux mediante SSH es una de las tareas más importantes para cualquier administrador de sistemas, desarrollador, especialista DevOps o responsable de infraestructura. SSH permite administrar servidores desde una terminal remota, transferir archivos, ejecutar comandos, crear túneles seguros y operar sistemas sin necesidad de estar físicamente frente al equipo.
Sin embargo, SSH también es uno de los servicios más atacados cuando queda expuesto a Internet. Por eso, no basta con instalar OpenSSH y dejar el puerto abierto. Es necesario aplicar una configuración segura: usar claves públicas, desactivar acceso directo como root, limitar usuarios, proteger el firewall, registrar intentos de conexión y revisar periódicamente los logs.
Idea clave: SSH es seguro cuando se configura correctamente. El riesgo aparece cuando se permite acceso con contraseñas débiles, usuarios innecesarios, root directo, puertos abiertos sin control o servidores sin monitoreo.
¿Qué es SSH y por qué es esencial en Linux?
SSH, Secure Shell, es un protocolo utilizado para acceder de forma segura a sistemas remotos. En Linux, normalmente se implementa mediante OpenSSH, que incluye cliente, servidor y herramientas relacionadas para autenticación, cifrado y administración remota.
El cliente SSH se usa desde el equipo del administrador para conectarse al servidor. El servidor SSH, conocido como sshd, escucha conexiones entrantes y aplica las reglas definidas en su archivo de configuración. Según el manual de OpenSSH, el archivo ~/.ssh/authorized_keys lista las claves públicas permitidas para iniciar sesión en una cuenta remota.
SSH permite
- Administrar servidores Linux de forma remota.
- Ejecutar comandos en servidores.
- Usar autenticación por clave pública.
- Transferir archivos de forma segura con
scposftp. - Crear túneles cifrados para servicios internos.
- Automatizar tareas con Ansible, scripts o CI/CD.
- Gestionar infraestructura sin exponer paneles gráficos.
Paso 1: instalar OpenSSH Server
En muchas distribuciones de servidor, OpenSSH ya viene instalado. Si no está disponible, puedes instalarlo desde los repositorios oficiales de tu distribución.
Ubuntu o Debian
sudo apt update sudo apt install openssh-server -y sudo systemctl enable --now ssh sudo systemctl status ssh
Rocky Linux, AlmaLinux, RHEL o Fedora
sudo dnf install openssh-server -y sudo systemctl enable --now sshd sudo systemctl status sshd
Para conectarte desde otro equipo:
ssh usuario@IP_DEL_SERVIDOR
Resultado esperado: el servicio debe estar activo y escuchando conexiones entrantes. En Ubuntu/Debian suele llamarse ssh; en RHEL/Rocky/AlmaLinux/Fedora suele llamarse sshd.
Paso 2: crear un usuario administrativo sin usar root
No es recomendable administrar servidores conectándose directamente como root. Red Hat advierte que habilitar el inicio de sesión como root no es una práctica segura porque dificulta auditar qué usuario ejecutó comandos privilegiados. Lo recomendable es usar una cuenta normal y elevar permisos con sudo cuando sea necesario.
# Crear usuario sudo adduser adminlinux # Agregar a sudo en Ubuntu/Debian sudo usermod -aG sudo adminlinux # Agregar a wheel en Rocky/AlmaLinux/RHEL/Fedora sudo usermod -aG wheel adminlinux
Prueba conexión con ese usuario:
ssh adminlinux@IP_DEL_SERVIDOR
Tip: antes de bloquear root, confirma que puedes entrar con el nuevo usuario y ejecutar comandos con sudo.
Paso 3: generar claves SSH en el equipo cliente
La autenticación por clave pública es más segura que depender únicamente de contraseñas. El cliente conserva una clave privada y el servidor almacena la clave pública autorizada en el archivo ~/.ssh/authorized_keys.
En tu equipo local, genera un par de claves:
ssh-keygen -t ed25519 -C "adminlinux@servidor"
Durante la creación, es recomendable proteger la clave privada con una frase de paso. Esto agrega una capa de seguridad si el equipo cliente se pierde o queda comprometido.
No compartas tu clave privada: el archivo sin extensión, por ejemplo id_ed25519, debe permanecer únicamente en tu equipo cliente y con permisos restrictivos.
Paso 4: copiar la clave pública al servidor
La forma más sencilla es usar ssh-copy-id. Este comando copia tu clave pública al archivo authorized_keys del usuario remoto.
ssh-copy-id adminlinux@IP_DEL_SERVIDOR
Prueba el acceso:
ssh adminlinux@IP_DEL_SERVIDOR
Si necesitas hacerlo manualmente, en el servidor asegúrate de que existan los archivos y permisos correctos:
mkdir -p ~/.ssh chmod 700 ~/.ssh nano ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys chmod 700 ~/.ssh
Buena práctica: cada administrador debe usar su propia clave SSH. No compartas una misma clave privada entre varios usuarios.
Paso 5: editar la configuración segura de SSH
El archivo principal de configuración del servidor SSH es /etc/ssh/sshd_config. El manual de sshd_config indica que el demonio SSH lee ese archivo para aplicar opciones de configuración mediante pares clave-valor.
Antes de editar, crea una copia de seguridad:
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak sudo nano /etc/ssh/sshd_config
Configuración recomendada de endurecimiento inicial:
# Puerto SSH Port 22 # No permitir acceso directo como root PermitRootLogin no # Usar autenticación por clave pública PubkeyAuthentication yes # Desactivar contraseñas después de validar claves PasswordAuthentication no # Desactivar autenticación interactiva por contraseña KbdInteractiveAuthentication no # Limitar usuarios permitidos AllowUsers adminlinux # Reducir intentos de autenticación MaxAuthTries 3 # Reducir sesiones simultáneas MaxSessions 3 # Evitar reenvío X11 si no se usa X11Forwarding no # Mostrar menos información antes del login DebianBanner no
Precaución: no configures PasswordAuthentication no hasta confirmar que puedes entrar correctamente con clave pública. Si lo haces antes, podrías perder acceso remoto.
Paso 6: validar la configuración antes de reiniciar SSH
Antes de reiniciar el servicio, valida que el archivo no tenga errores de sintaxis:
sudo sshd -t
Si no muestra errores, reinicia el servicio.
Ubuntu o Debian
sudo systemctl restart ssh sudo systemctl status ssh
Rocky Linux, AlmaLinux, RHEL o Fedora
sudo systemctl restart sshd sudo systemctl status sshd
Luego abre una nueva terminal e intenta conectar:
ssh adminlinux@IP_DEL_SERVIDOR
Recomendación crítica: mantén abierta tu sesión SSH original mientras pruebas una nueva conexión. Cierra la sesión antigua solo cuando confirmes que todo funciona.
Paso 7: proteger SSH con firewall
Si el servidor está expuesto a Internet, el firewall debe permitir SSH solo desde IPs autorizadas cuando sea posible. Ubuntu documenta UFW como una herramienta sencilla para crear un firewall IPv4 o IPv6 basado en host.
UFW en Ubuntu o Debian
# Permitir SSH desde una IP específica sudo ufw allow from 203.0.113.10 to any port 22 proto tcp # Permitir HTTP/HTTPS si el servidor publica web sudo ufw allow 80/tcp sudo ufw allow 443/tcp # Activar firewall sudo ufw enable # Ver reglas sudo ufw status verbose
firewalld en Rocky Linux, AlmaLinux, RHEL o Fedora
# Permitir SSH sudo firewall-cmd --permanent --add-service=ssh # Permitir SSH solo desde una IP específica con rich rule sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="203.0.113.10" service name="ssh" accept' # Recargar reglas sudo firewall-cmd --reload # Ver reglas sudo firewall-cmd --list-all
Tip: si tu IP pública cambia con frecuencia, evalúa acceso por VPN, bastion host o reglas temporales controladas. No abras SSH a todo Internet si puedes evitarlo.
Paso 8: cambiar el puerto SSH, ¿sí o no?
Cambiar el puerto 22 puede reducir ruido de bots automáticos, pero no reemplaza una configuración segura. Si cambias el puerto, debes actualizar firewall, documentación, scripts, monitoreo y comandos de conexión.
En /etc/ssh/sshd_config:
Port 2222
Validar y reiniciar:
sudo sshd -t sudo systemctl restart ssh
Conectar usando el nuevo puerto:
ssh -p 2222 adminlinux@IP_DEL_SERVIDOR
Importante: cambiar el puerto no sustituye claves SSH, firewall, bloqueo de root, contraseñas desactivadas y monitoreo de logs.
Paso 9: usar archivo de configuración del cliente SSH
Para evitar escribir IP, usuario, puerto y clave cada vez, puedes crear una entrada en el archivo ~/.ssh/config de tu equipo local.
nano ~/.ssh/config
Ejemplo:
Host servidor-produccion
HostName 203.0.113.20
User adminlinux
Port 2222
IdentityFile ~/.ssh/id_ed25519
IdentitiesOnly yes
Conexión simplificada:
ssh servidor-produccion
Paso 10: revisar logs de acceso SSH
Los logs permiten detectar intentos fallidos, usuarios inexistentes, fuerza bruta, conexiones sospechosas y errores de autenticación. Deben revisarse de forma periódica o integrarse a un sistema de monitoreo.
Ubuntu o Debian
sudo journalctl -u ssh --since "24 hours ago" sudo grep "Failed password" /var/log/auth.log | tail -50 sudo grep "Accepted" /var/log/auth.log | tail -50
Rocky Linux, AlmaLinux, RHEL o Fedora
sudo journalctl -u sshd --since "24 hours ago" sudo grep "Failed password" /var/log/secure | tail -50 sudo grep "Accepted" /var/log/secure | tail -50
Recomendación: si un servidor recibe muchos intentos fallidos, revisa firewall, exposición pública, usuarios permitidos y herramientas de bloqueo automático como Fail2ban.
Paso 11: proteger SSH con Fail2ban
Fail2ban puede bloquear temporalmente direcciones IP que generan múltiples intentos fallidos. Es una capa adicional útil, especialmente en servidores expuestos públicamente.
Ubuntu o Debian
sudo apt install fail2ban -y sudo systemctl enable --now fail2ban
Configuración básica
sudo nano /etc/fail2ban/jail.local
Contenido sugerido:
[sshd] enabled = true port = ssh maxretry = 3 findtime = 10m bantime = 1h
Reiniciar y verificar:
sudo systemctl restart fail2ban sudo fail2ban-client status sudo fail2ban-client status sshd
Tip: si cambiaste el puerto SSH, ajusta también la configuración de Fail2ban para que vigile el puerto correcto.
Configuración recomendada para un servidor de producción
| Control | Recomendación | Objetivo |
|---|---|---|
| Autenticación | Usar claves SSH. | Reducir riesgo de contraseñas débiles. |
| Root | Configurar PermitRootLogin no. |
Mejorar trazabilidad y reducir riesgo. |
| Contraseñas | Configurar PasswordAuthentication no. |
Forzar autenticación por clave. |
| Usuarios | Usar AllowUsers o grupos permitidos. |
Limitar quién puede entrar por SSH. |
| Firewall | Permitir SSH solo desde IPs autorizadas. | Reducir superficie de ataque. |
| Logs | Revisar journalctl, auth.log o secure. |
Detectar intentos sospechosos. |
Errores comunes al configurar SSH
Errores que debes evitar
- Desactivar contraseñas antes de probar claves SSH.
- Reiniciar SSH sin validar con
sshd -t. - Cerrar la única sesión activa antes de confirmar la nueva conexión.
- Permitir acceso directo como root.
- Compartir una misma clave privada entre varios administradores.
- Dejar SSH abierto a todo Internet sin firewall.
- Usar contraseñas débiles o reutilizadas.
- No revisar logs de autenticación.
- No documentar cambios en puerto, usuarios o claves.
- No tener acceso alternativo por consola del proveedor o KVM.
Checklist rápido de SSH seguro
- Instalar y habilitar OpenSSH Server.
- Crear usuario administrativo sin usar root.
- Generar clave SSH con
ssh-keygen. - Copiar clave pública con
ssh-copy-id. - Confirmar acceso con clave pública.
- Configurar
PermitRootLogin no. - Configurar
PasswordAuthentication nosolo después de validar claves. - Limitar usuarios con
AllowUsers. - Proteger puerto SSH con firewall.
- Validar configuración con
sshd -t. - Reiniciar el servicio y probar desde una nueva sesión.
- Revisar logs y activar Fail2ban si corresponde.
Artículos que recomendamos
- Guía práctica de ciberseguridad: cómo proteger servidores Linux frente a ataques comunes
- Cómo configurar un firewall en Linux para proteger tu infraestructura
- Cómo detectar si tu servidor Linux tiene problemas de seguridad
- Guía básica para administrar usuarios y permisos en Linux
- Las herramientas open source más utilizadas por administradores de sistemas en 2026
Tip final: una buena configuración SSH debe combinar claves públicas, usuarios limitados, root deshabilitado, firewall, logs, monitoreo y documentación. Ningún control por sí solo es suficiente.
Conclusión
Configurar acceso remoto seguro mediante SSH es una tarea esencial para proteger servidores Linux. OpenSSH permite administración remota cifrada, pero debe configurarse con buenas prácticas: claves públicas, usuarios administrativos separados, bloqueo de root, desactivación de contraseñas, firewall, logs y herramientas de protección adicional.
El proceso recomendado es progresivo: primero instalar SSH, crear un usuario seguro, generar claves, probar acceso, validar permisos, ajustar sshd_config, proteger el firewall y revisar logs. Nunca apliques cambios críticos sin mantener una sesión activa de respaldo.
En entornos de producción, SSH debe tratarse como un servicio crítico. Cada clave, usuario, puerto, regla de firewall y cambio de configuración debe estar documentado, monitoreado y revisado periódicamente.
Resumen final
Para configurar SSH seguro en Linux, instala OpenSSH Server, crea un usuario administrativo, genera claves SSH, copia la clave pública al servidor, valida el acceso, desactiva root, desactiva contraseñas después de probar claves, limita usuarios, protege el puerto con firewall, revisa logs y considera Fail2ban. Antes de reiniciar SSH, valida siempre con sshd -t y conserva una sesión abierta de respaldo.
