Las 10 primeras cosas que hago en un servidor Linux nuevo 2026

blockquote>

Este es el checklist que aplico cada vez que recibo un servidor Linux nuevo, sea un VPS en Hetzner, una VM en Proxmox o un bare-metal dedicado. Diez pasos, en orden, antes de poner el servidor a producción o exponer cualquier servicio a internet. Los comandos están pensados para Ubuntu/Debian y RHEL/Fedora en paralelo — si tu distro es otra (openSUSE, Arch), la lógica es la misma aunque los comandos cambian. El orden importa: cada paso construye sobre el anterior, y saltarse uno te deja con un hueco explotable.

1. Actualizar todo antes de tocar nada

El primer impulso cuando entras a un servidor nuevo es empezar a instalar cosas. Resiste. La imagen base que te dio el proveedor tiene entre 30 días y 6 meses de paquetes sin actualizar, y hay parches de seguridad recientes que necesitas antes de exponer nada. Una vulnerabilidad sin parchear en openssh-server o en glibc es exactamente lo que un atacante busca cuando te escanean.

En Debian/Ubuntu:

sudo apt update && sudo apt full-upgrade -y
sudo systemctl reboot

En RHEL/Fedora/Rocky/Alma:

sudo dnf upgrade -y
sudo systemctl reboot

El reboot es importante porque el kernel nuevo no se carga hasta el siguiente boot. Si después vas a instalar drivers o configurar cosas de bajo nivel (ZFS, WireGuard, módulos del kernel), necesitas estar en el kernel nuevo desde el primer minuto. Si el servidor está en producción y no puedes reiniciar, al menos confirma qué versión de kernel tienes corriendo con uname -r y planea una ventana de mantenimiento.

Troubleshooting común: si el apt update falla con NO_PUBKEY en un servidor que alguien tocó antes, las claves GPG están corruptas. apt-key está deprecado desde Debian 11/Ubuntu 22.04: regenerá las claves manualmente y agregalas con signed-by= en /etc/apt/sources.list.d/ (las nuevas van en /etc/apt/keyrings/).

2. Crear un usuario con sudo y bloquear root

El usuario root debería existir solo para emergencias. Trabajar siempre como root es el patrón #1 que te hace perder un servidor: un rm -rf en el directorio equivocado, un script descargado que ejecuta con privilegios completos, un atacante que entra y ya es administrador.

Crea tu usuario y dale sudo sin password (con timeout corto para que te pida cada N minutos):

# Crear usuario (cambia 'roger' por el tuyo)
sudo adduser roger
sudo usermod -aG sudo roger
# En RHEL/Fedora el grupo es 'wheel'
sudo usermod -aG wheel roger
# Verificar que funciona
sudo -lU roger

Ahora la parte que casi nadie hace y salva servidores: edita /etc/sudoers con sudo visudo y agrega un alias que registre cada comando sudo a syslog. Si te entran al server, vas a tener un log forense de exactamente qué ejecutó el atacante:

Defaults log_host, log_year, logfile=/var/log/sudo.log
Defaults passwd_timeout=2
Defaults timestamp_timeout=5

passwd_timeout=2 te da 2 minutos entre pedidos de password cuando estás haciendo varias cosas. timestamp_timeout=5 te recuerda el password por 5 minutos entre comandos. Para un servidor donde solo tú entras es cómodo. Para servidores compartidos baja ambos a 1.

Troubleshooting: si después de agregar el usuario no puedes loguearte por SSH con él, el problema es 99% que tu proveedor de nube (DigitalOcean, AWS, Hetzner) tiene una config que fuerza login como root vía cloud-init. Edita /etc/ssh/sshd_config y verifica que PermitRootLogin esté en no antes de seguir.

3. Copiar tu clave SSH y desactivar password auth

Antes de cerrar root, asegurate de que tu clave pública está en el servidor del usuario nuevo. Si no, vas a quedar afuera. El flujo correcto es desde tu máquina local, no desde el servidor:

# En tu workstation (NO en el servidor)
ssh-copy-id -i ~/.ssh/id_ed25519.pub roger@mi-servidor
# Si no tienes clave, genera una primero
ssh-keygen -t ed25519 -a 100 -C "[email protected]"

Una vez que confirmaste que puedes entrar como roger con tu clave, es hora de matar la autenticación por password. Edita /etc/ssh/sshd_config con sudo nano /etc/ssh/sshd_config y cambia estas directivas:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey
PermitEmptyPasswords no
KbdInteractiveAuthentication no
UsePAM yes

Aplica sin reiniciar (para verificar que la config es válida antes de quedarte afuera):

sudo sshd -t && sudo systemctl reload ssh
# En Debian/Ubuntu a veces el servicio se llama 'ssh'
sudo systemctl reload ssh

No cierres la sesión actual. Abrí una segunda conexión SSH al servidor como roger. Si entras, la config está bien. Si no, vuelve a la sesión original (que sigue abierta) y revisa los logs con sudo journalctl -u ssh -n 50. El 90% de los casos es que sshd -t pasó pero AuthenticationMethods publickey bloqueó tu clave porque PubkeyAuthentication quedó comentada.

Troubleshooting: si después de cambiar la config te aparece Permission denied (publickey), verifica tres cosas en orden: (1) que tu clave esté en ~/.ssh/authorized_keys con permisos 600 y directorio 700; (2) que PubkeyAuthentication yes esté descomentado; (3) que el SELinux contexto del home no esté roto (restorecon -R ~/.ssh en Fedora/RHEL).

4. Cambiar el puerto de SSH (defensa adicional, no principal)

Esto no es seguridad real — un atacante con un escaneo de puertos te encuentra en 10 segundos — pero reduce el ruido en tus logs por un 95%. Los bots que recorren internet prueban ssh en el puerto 22 contra millones de IPs; si moviste el puerto, no te ven.

En /etc/ssh/sshd_config:

Port 2222
# O cualquier puerto alto no usado entre 1024 y 65535

Ajusta el firewall antes de recargar, sino te quedas afuera:

sudo ufw allow 2222/tcp
sudo ufw delete allow 22/tcp   # Si lo tenías abierto
sudo ufw reload
sudo sshd -t && sudo systemctl reload ssh

Para conectarte ahora:

ssh -p 2222 roger@mi-servidor
# O agregalo a ~/.ssh/config para no tipearlo siempre
Host mi-server
    HostName mi-servidor
    Port 2222
    User roger
    IdentityFile ~/.ssh/id_ed25519

Troubleshooting: si usas ufw y SSH está en un puerto custom, también actualiza /etc/fail2ban/jail.local cuando llegues al paso 7 (cambio el port en la jail de SSH). Si usas un firewall externo (cloud provider, OPNsense), abrí el nuevo puerto y cierra el viejo antes de hacer el cambio.

5. Activar el firewall (UFW o firewalld)

El firewall por default de las distros modernas permite todo de salida y nada de entrada. Eso está bien como punto de partida, pero necesitas una regla explícita para SSH y otra para cada servicio que expongas.

En Debian/Ubuntu con UFW:

sudo apt install -y ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 2222/tcp comment "SSH custom port"
sudo ufw enable
sudo ufw status verbose

En RHEL/Fedora/Rocky/Alma con firewalld (ya viene activo):

sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --permanent --remove-service=ssh
sudo firewall-cmd --reload
sudo firewall-cmd --list-all

Política que sigo: solo abrir puertos cuando un servicio los necesita, no antes. Si después instalas Caddy para un reverse proxy, agregas 443/tcp cuando Caddy esté listo, no antes. Y nunca exponer una base de datos directamente: el cliente siempre va por el proxy o por un túnel SSH.

Troubleshooting: si después de activar UFW pierdes conectividad, puede ser que tu proveedor de nube tenga reglas de firewall a nivel hypervisor que están bloqueando el tráfico antes que UFW lo vea. En ese caso, UFW está bien y el problema está en el panel del proveedor (Hetzner Cloud Firewall, AWS Security Groups, etc.).

6. Sincronizar la hora con NTP

Un servidor con la hora mal sincronizada te rompe todo lo que usa timestamps: logs forenses, certificados TLS, replicación de bases de datos, cron jobs. La causa #1 de “mi certificado Let’s Encrypt no renovó” es que el reloj del server está 5 minutos adelante.

systemd-timesyncd viene por default en la mayoría de las distros modernas y es suficiente para la mayoría de casos:

sudo timedatectl set-ntp true
sudo timedatectl status

Si quieres más control (por ejemplo, usar tu propio servidor NTP en la red), instala chrony:

sudo apt install -y chrony
# O en RHEL/Fedora
sudo dnf install -y chrony
sudo systemctl enable --now chrony
chronyc tracking
chronyc sources -v

Configuro chrony con al menos 4 servidores de fuentes distintas. Para servidores europeos, los del proyecto pool.ntp.org funcionan bien:

# /etc/chrony/chrony.conf (agregar)
pool pool.ntp.org iburst
pool time.cloudflare.com iburst
# maxsources es directiva top-level (limita el total de fuentes entre todos los pools)
maxsources 4
makestep 1.0 3
rtcsync

Troubleshooting: si ves System clock wrong by en chronyc tracking, es probable que tu firewall esté bloqueando UDP/123. Abrilo y reinicia chrony. En máquinas virtuales, también puede ser que el hypervisor esté sincronizando el reloj por su cuenta y chrony pelee contra él — en ese caso, makestep 1.0 3 fuerza una sincronización inmediata.

7. Instalar fail2ban para mitigar brute force

fail2ban lee los logs de SSH y banea IPs que fallan login N veces. No reemplaza al firewall pero lo complementa: si alguien insiste con un ataque distribuido, al menos cada IP individual queda afuera después de unos intentos.

Instalación y jail por default:

sudo apt install -y fail2ban
# O
sudo dnf install -y fail2ban
sudo systemctl enable --now fail2ban

Crea /etc/fail2ban/jail.local con overrides (nunca edites jail.conf directo, se sobrescribe en updates):

[DEFAULT]
bantime  = 1h
findtime = 10m
maxretry = 5
banaction = ufw
[sshd]
enabled = true
port    = 2222
backend = systemd
logpath = %(sshd_log)s

Verifica que esté activo:

sudo fail2ban-client status
sudo fail2ban-client status sshd

Troubleshooting: si después de instalar no banea a nadie, revisa que /var/log/auth.log (o /var/log/secure en RHEL) exista y tenga contenido. En algunos contenedores Docker ese archivo no existe porque el servicio de log está deshabilitado. Otro caso común: si cambiaste el puerto de SSH, fail2ban necesita la directiva port = 2222 en la jail, sino no matchea los intentos.

8. Automatizar actualizaciones de seguridad

No puedes patchear manualmente cada CVE. Pero puedes hacer que tu servidor instale solo los parches de seguridad, dejando los upgrades mayores para ti.

En Debian/Ubuntu con unattended-upgrades:

sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades
# Configurar para que solo aplique security updates automático
sudo tee /etc/apt/apt.conf.d/50unattended-upgrades-security-only > /dev/null <<EOF
Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
};
Unattended-Upgrade::AutoFixInterruptedDpkg "true";
Unattended-Upgrade::MinimalSteps "true";
Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
Unattended-Upgrade::Remove-Unused-Dependencies "true";
Unattended-Upgrade::Automatic-Reboot "false";
EOF

En RHEL/Fedora/Rocky/Alma con dnf-automatic:

sudo dnf install -y dnf-automatic
sudo systemctl enable --now dnf-automatic.timer
# /etc/dnf/automatic.conf
[commands]
upgrade_type = security
download_updates = yes
apply_updates = yes
[emitters]
emit_via = motd

Para servidores de producción críticos donde necesitas control fino, deshabilito el auto-reboot y dejo que un cron semanal te avise por mail qué se actualizó. Para servidores personales o de homelab, auto-apply con notificación es suficiente.

Troubleshooting: si unattended-upgrades no está corriendo, revisa sudo systemctl status unattended-upgrades. En Ubuntu Server el timer está habilitado por default; en otras distros hay que activarlo manualmente con sudo systemctl enable --now unattended-upgrades.timer. Los logs quedan en /var/log/unattended-upgrades/.

9. Configurar hostname, /etc/hosts y timezone

El hostname por default de un VPS suele ser algo como vmi1234567.contaboserver.com. Eso filtra tu proveedor y mete ruido en los logs. Cambialo a algo descriptivo del rol del servidor:

sudo hostnamectl set-hostname prod-api-01
sudo hostnamectl set-location "DC Montreal, rack 12"
sudo hostnamectl status

Edita /etc/hosts para que el hostname resuelva localmente (algunos servicios lo asumen):

127.0.0.1   localhost
127.0.1.1   prod-api-01.mi-dominio.com prod-api-01
# IPv6
::1         localhost ip6-localhost ip6-loopback
ff02::1     ip6-allnodes
ff02::2     ip6-allrouters

Y la timezone. Casi siempre UTC para servidores (logs más fáciles de correlacionar entre máquinas):

sudo timedatectl set-timezone UTC
date
# Verifica que diga UTC. Si dice EDT o CET, ajusta.

Troubleshooting: si después de cambiar el hostname algunos servicios siguen mostrando el viejo, revisa si tu distro cachea el hostname en algún archivo. Debian guarda una copia en /etc/mailname (para Postfix) y en el prompt de bash. RHEL tiene que regenerar /etc/rsyslog.d/ si quieres que los logs muestren el hostname nuevo.

10. Configurar backups automatizados

El paso más importante y el que más gente se salta. No es backup hasta que probaste restaurar. La diferencia entre un respaldo y un respaldo testeado es la diferencia entre dormir tranquilo y tener un domingo muy malo.

Mi setup default: restic + systemd timer + destino S3-compatible (Hetzner Storage Box, Backblaze B2, MinIO propio).

sudo apt install -y restic
# O
sudo dnf install -y restic
# Inicializar el repo (una sola vez)
export AWS_ACCESS_KEY_ID="tu_key"
export AWS_SECRET_ACCESS_KEY="tu_secret"
restic -r s3:s3.tu-storage.com/backups init
# Hacer el primer backup manual para probar
restic -r s3:s3.tu-storage.com/backups backup /etc /home /var/www /opt

Automatizar con systemd timer:

sudo tee /etc/systemd/system/restic-backup.service > /dev/null <<EOF
[Unit]
Description=Restic backup
[Service]
Type=oneshot
Environment="AWS_ACCESS_KEY_ID=tu_key"
Environment="AWS_SECRET_ACCESS_KEY=tu_secret"
ExecStart=/usr/bin/restic -r s3:s3.tu-storage.com/backups backup /etc /home /var/www /opt
ExecStartPost=/usr/bin/restic -r s3:s3.tu-storage.com/backups forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6
EOF
sudo tee /etc/systemd/system/restic-backup.timer > /dev/null <<EOF
[Unit]
Description=Daily Restic backup
[Timer]
OnCalendar=daily
OnCalendar=02:00
Persistent=true
[Install]
WantedBy=timers.target
EOF
sudo systemctl daemon-reload
sudo systemctl enable --now restic-backup.timer

Test de restore obligatorio antes de dar por terminado:

# Listar qué hay en el repo
restic -r s3:s3.tu-storage.com/backups snapshots
# Restaurar un archivo específico
restic -r s3:s3.tu-storage.com/backups restore latest --target /tmp/restore-test --include /etc/nginx

Si la restauración funciona, recién ahí puedes decir que tienes backups. Si no probaste restaurar, no tienes backups, tienes esperanza.

Troubleshooting: si restic backup falla con errores de permisos en /var/lib/private, agrega --exclude-file=/etc/restic-excludes.txt con paths a excluir. Si falla con errores de S3, verifica que las claves tengan permisos s3:PutObject y que el bucket exista. Y muy importante: guarda las credenciales de restic en un archivo aparte (/etc/restic.env con permisos 600) en vez de hardcodearlas en el unit file — si commiteas el unit file a un repo público, las credenciales se filtran.

Conclusión

Diez pasos, alrededor de 30 a 45 minutos si los haces en una sola sesión. El resultado: un servidor que pasó de “público y vulnerable” a “mínimo aceptable para producción”. Eso no es el final — hay capas adicionales que entran según qué vas a exponer (fail2ban para SSH es solo el piso; nginx con rate limiting, CrowdSec para L7, CrowdSec para el stack completo). Pero con esto ya tienes una base que resiste los escaneos automatizados que barren internet 24/7.

Si tienes que saltearte uno, no saltes el 2 (usuario + sudo) ni el 10 (backups). Los demás son importantes pero tienen mitigaciones; estos dos son los que te salvan cuando todo lo demás falla.

Lee también: Hardening SSH en 2026: 10 cambios que deberías hacer hoy para profundizar en el paso 3 de este checklist, Fail2ban: protege tu servidor SSH contra ataques de fuerza bruta si quieres extender la protección más allá de SSH, y Cron y systemd timers en Linux: automatiza todo en 2026 para dominar la herramienta que vas a usar en los pasos 8 y 10.

Preguntas frecuentes

Lee también

• Guía Fedora 44: Novedades, Instalación y Upgrade para Sysadmins Linux
• Configura VLANs en Linux con nmcli: Guía paso a paso para sysadmins
• Protege tu SSH: Guía esencial para configurar Fail2ban en Linux
• Guía Definitiva: Configura Kubernetes con kubeadm en Ubuntu para Sysadmins Linux
• Configura Prometheus y Grafana: Guía DevOps para SysAdmins Linux