Inicialización completa de Ubuntu: usuarios, SSH y seguridad con fail2ban

A las tres de la madrugada miraba el terminal: «Permission denied». Me sudaban las manos.

No podía entrar al servidor. Solo porque había tocado la configuración SSH sin dejar una salida de emergencia.

Eso fue hace tres años, con mi primer VPS. Fui un manual de errores: root directo, contraseña de cumpleaños, puerto 22 por defecto, sin firewall. En dos semanas el servidor estaba lleno de intentos de fuerza bruta en los logs.

Muchos recién llegados quieren instalar y desplegar ya. Usuarios, SSH endurecido… «para después». Pero eso define cuánto tiempo vivirá tu servidor.

Este artículo configura un Ubuntu recién comprado (22.04 o 24.04) de forma segura y usable: usuarios, SSH y fail2ban. En cada paso explico el porqué, no solo los comandos.

Unos 10 minutos. Al terminar, tu servidor estará por encima del 80% de máquinas «a pelo» en internet.

1. Preparación antes de empezar

Antes de tocar el servidor, genera un par de claves SSH en local.

¿Por qué clave y no contraseña? Las contraseñas se pueden adivinar o romper por fuerza bruta. Una clave Ed25519 de 256 bits es inviable de crackear en la práctica.

Generación de claves

Ed25519 es más seguro y corto que RSA antiguo:

# macOS / Linux
ssh-keygen -t ed25519 -C "[email protected]"

# Windows (PowerShell, con cliente OpenSSH)
ssh-keygen -t ed25519 -C "[email protected]"

Te preguntará ruta y passphrase. La ruta por defecto suele bastar; la passphrase es opcional (más segura, pero la pides en cada conexión).

Tras generar tendrás:

Vultr - Servidor cloud NVMe de alto rendimiento, 32 ubicaciones globales, despliegue Docker con un clic

Ver precios →Anuncio

• ~/.ssh/id_ed25519 — clave privada, nunca la compartas
• ~/.ssh/id_ed25519.pub — clave pública para el servidor

2. Usuarios y permisos

Entra primero como root (será la última vez):

ssh root@TU_IP_DEL_SERVIDOR

¿Por qué no usar root?

Las consecuencias de un error son enormes: un archivo borrado o una línea mal puesta y el sistema cae. Además, muchos scripts atacan root por SSH.

Opera con un usuario normal y usa sudo cuando haga falta. Es la regla básica de seguridad en Linux.

Crear usuario de despliegue

Uso deploy; puedes elegir otro nombre:

# Crear usuario (pedirá contraseña e información)
adduser deploy

# Añadir a sudo
usermod -aG sudo deploy

La contraseña debe ser memorable; el resto de campos puedes dejarlos en blanco con Enter.

Subir la clave pública

En tu máquina local:

# macOS / Linux
ssh-copy-id deploy@TU_IP_DEL_SERVIDOR

# Windows (PowerShell)
type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh deploy@TU_IP_DEL_SERVIDOR "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Prueba el acceso:

ssh deploy@TU_IP_DEL_SERVIDOR

Si funciona, sigue con deploy. Para privilegios elevados, sudo.

Varios usuarios

En equipos, una cuenta por persona:

adduser zhangsan
usermod -aG sudo zhangsan
# Cada uno ejecuta en local: ssh-copy-id zhangsan@TU_IP

Así las acciones quedan trazables.

3. Endurecimiento SSH

Es el paso más crítico y el que más «cerrones fuera» provoca.

Advertencia: no cierres la sesión actual. Abre otra terminal para probar cada cambio.

Editar sshd_config

sudo nano /etc/ssh/sshd_config

Parámetros clave

1. Port

Port 22    # valor por defecto; cámbialo

El 22 es el blanco favorito de escaneos. Un puerto alto (22222, 54321) evita la mayoría de bots genéricos.

Port 54321

En cloud (AWS, GCP, Alibaba, Tencent), abre el nuevo puerto en el grupo de seguridad.

2. PermitRootLogin

Railway - Plataforma de despliegue moderna, sin ops complejas, en producción en minutos

Empezar ahora →Anuncio

PermitRootLogin no

Reduce mucho la superficie de ataque.

3. PasswordAuthentication

PasswordAuthentication no

Sin contraseñas por SSH, la fuerza bruta pierde sentido si tu clave privada está segura.

4. Otros parámetros

MaxAuthTries 3
ClientAliveInterval 300
ClientAliveCountMax 2

Limitan intentos y cierran sesiones inactivas.

Verificación en tres pasos

Paso 1: sintaxis

sudo sshd -t

Sin salida = sintaxis correcta.

Paso 2: nueva ventana

ssh -p 54321 deploy@TU_IP_DEL_SERVIDOR

Si conecta, la configuración funciona y no te quedaste fuera.

Paso 3: reiniciar

sudo systemctl restart sshd
# o
sudo systemctl restart ssh

Prueba otra vez desde la ventana nueva.

Si algo falla

Usa la consola VNC del proveedor, revierte cambios y reinicia sshd. Por eso insistimos en dejar una sesión abierta.

4. fail2ban: bloqueo automático

SSH endurecido frena muchos ataques. fail2ban vigila logs y banea IPs sospechosas tras varios fallos.

Instalación

sudo apt update
sudo apt install fail2ban -y
sudo systemctl enable fail2ban
sudo systemctl start fail2ban

Configurar la «jail» sshd

No edites los archivos por defecto (se pierden en actualizaciones). Crea jail.local:

Alibaba Cloud - Opción preferida para desarrolladores, 15 % de descuento exclusivo en Lighthouse

Obtener 15% dto. →Anuncio

sudo nano /etc/fail2ban/jail.local

Contenido:

[sshd]
enabled = true
port = 54321          # tu puerto SSH
maxretry = 3
findtime = 600        # ventana de 10 minutos
bantime = 3600        # ban de 1 hora

• maxretry: intentos antes del ban (por defecto 5; aquí 3)
• findtime: segundos de la ventana
• bantime: duración del ban (86400 = un día)

Reinicia:

sudo systemctl restart fail2ban

Ver estado

sudo fail2ban-client status
sudo fail2ban-client status sshd

Verás la lista de IPs baneadas.

Desbanear una IP

sudo fail2ban-client set sshd unbanip TU_IP

fail2ban también puede proteger Nginx, Apache, MySQL, etc., con jails similares.

5. Diferencias entre versiones

Buenas noticias: usuarios, rutas de SSH y fail2ban son iguales en ambas.

A tener en cuenta:

1. OpenSSH 9.x (24.04) deshabilita algoritmos viejos; clientes SSH antiguos pueden fallar — actualiza el cliente.
2. Imágenes de cloud: algunas traen agentes preinstalados; mejor imagen oficial limpia o revisa servicios antes de endurecer.
3. Upgrade 22→24: haz snapshot antes de do-release-upgrade.

¿Cuál elegir?

• Proyecto nuevo: 24.04 (soporte más largo, software más reciente)
• Dependencias en 3.10: 22.04
• Máxima estabilidad probada: 22.04
• Hardware nuevo / rendimiento: 24.04

Resumen

Tres pilares de seguridad:

• Usuario normal; root sin login SSH
• Puerto alto, sin contraseñas, solo claves
• fail2ban para IPs sospechosas

Principios operativos:

• Sesión abierta al editar SSH
• Validar antes de reiniciar
• La clave privada no se comparte

Checklist:

• Login con deploy por el puerto nuevo
• root no puede entrar
• Autenticación por contraseña desactivada
• fail2ban activo

Esto es solo el primer paso. Después vienen firewall (UFW), Docker, despliegue de apps… lo veremos en otro momento.

Si te atascas siguiendo esta guía, comenta y lo vemos. Ese «Permission denied» a las tres de la mañana no es una experiencia que recomendaría a nadie.