Cómo configuro un VPS nuevo

Cada vez que contrato un servidor nuevo repito el mismo ritual antes de dejar que haga nada útil. No es un manual de comandos, aunque dejo los imprescindibles: es el orden en que hago las cosas, por qué las hago y los tropiezos que me enseñaron a no saltarme ningún paso.

Seguro que has visto el vídeo: «contrata un VPS, instala tu agente y a funcionar», cinco minutos y un señor sonriente. Y es verdad a medias: arrancar una máquina es rapidísimo. Dejarla segura, no.

Si no sabes qué es un VPS, piensa en un trozo de un servidor grande que alquilas y que se comporta como un ordenador entero para ti, encendido día y noche y conectado a internet.

Aquí voy a contar cómo configurar un VPS en el orden en que lo hago yo: elegir proveedor y máquina, primer acceso, usuarios y claves, cortafuegos y actualizaciones, copias de seguridad, lo que instalo siempre, mis errores y, al final, la lista de comprobación. Los comandos que pongo son para Ubuntu, que es lo que llevan mis seis VPS (revisado en septiembre de 2026 con la 24.04). En Debian son casi iguales; en la familia de Red Hat cambian los nombres (dnf, firewalld). El resto se lo puedes pedir a cualquier asistente diciéndole qué sistema tienes; lo que no te va a dar es el orden ni las razones, y eso es lo que me costó aprender.

Mis seis VPS no están todos en el mismo sitio. Tengo cuatro en Hetzner y dos en IONOS, y la razón es más prosaica de lo que parece. Hetzner lo elegí porque los centros de datos están en Europa, lo que me simplifica la conversación sobre dónde están los datos de los clientes, y porque su panel es sencillo. IONOS vino después, porque ya tenía allí dominios y correo y me resultaba cómodo tenerlo todo junto con el mismo soporte en español.

El tamaño lo decido por la función, no por el entusiasmo. Un VPS que solo recibe peticiones y las reparte puede ser pequeño, con dos núcleos y cuatro gigas de memoria. Uno que va a tener bases de datos o varios servicios a la vez lo cojo algo mayor, con ocho gigas. Ninguno lleva tarjeta gráfica: para eso tengo la red interna, y esa historia la cuento en Qué corre en cada una de mis máquinas.

En sistema, casi siempre Linux. Por qué, y cuándo no, está en Linux o Windows en mis servidores.

Un error de elección que sí cometí: al principio cogí el VPS más barato para un servicio que luego creció, y a los dos meses tuve que migrarlo a una máquina mayor un domingo por la tarde. Ahorré unos euros y perdí una tarde entera.

La primera vez entro como me deja el proveedor. En mi caso, el panel me permite dejar cargada mi clave pública al crear la máquina, así que el primer acceso ya es con clave y como administrador. Ese primer acceso es para una sola cosa: preparar la casa para no volver a entrar así.

Lo primero que hago es crear un usuario propio y darle permisos para hacer tareas de administración cuando lo pida de forma explícita. No trabajo con el usuario administrador por la misma razón por la que no vas por casa con el manojo de llaves de todo el edificio: si algo sale mal, el daño se queda más pequeño.

Luego, las claves de acceso. La diferencia con una contraseña se entiende con una comparación sencilla: la contraseña es un código que alguien puede adivinar si prueba el tiempo suficiente; la clave es una llave física que solo tienes tú. El servidor guarda la cerradura, tu ordenador guarda la llave, y sin la llave no hay nada que adivinar.

sudo adduser tuusuario
sudo usermod -aG sudo tuusuario
# copia tu clave pública a /home/tuusuario/.ssh/authorized_keys

Cuando compruebo que puedo entrar con mi usuario y mi clave, desactivo dos cosas: la entrada directa del administrador y la entrada con contraseña. Antes de aplicarlo, compruebo que la configuración no tiene errores:

# en /etc/ssh/sshd_config
PermitRootLogin no
PasswordAuthentication no

sudo sshd -t && sudo systemctl reload ssh

También cambio el puerto de acceso por defecto. Reduce el ruido en los registros, pero no protege por sí solo: lo que protege son las claves, limitar los intentos y tener el sistema al día. En el acceso remoto no uso doble factor; lo tengo activado en el panel del proveedor, porque quien entra ahí puede abrir la consola de emergencia y entrar en todo.

Y aquí viene el susto clásico. La segunda máquina que configuré la dejé sin contraseñas antes de comprobar que mi clave funcionaba con el usuario nuevo. Resultado: me quedé fuera de mi propio servidor. Tuve que entrar por la consola de emergencia del proveedor, que es como entrar en tu casa por la ventana del baño, y deshacer el entuerto. Desde entonces tengo una norma: nunca cierro la sesión abierta hasta haber entrado con éxito desde otra ventana, con ssh -p PUERTO tuusuario@IP.

Un cortafuegos es el filtro que decide qué conexiones entran en la máquina y cuáles se quedan en la puerta. Por defecto, en muchos VPS recién creados no hay ninguno activo, y todo lo que escuche está a la vista.

Mi criterio es cerrarlo todo y abrir solo lo necesario. En una máquina típica mía dejo abierto el acceso remoto y, si sirve una web, los puertos de la web. Nada más. Las bases de datos, los paneles de administración y los servicios internos no se abren al exterior: si necesito llegar a ellos, entro por el túnel hacia la red interna.

Con las actualizaciones hago lo mismo cada vez: las pongo al día antes de instalar nada. Una máquina recién creada viene con el sistema de cuando se preparó la imagen, que puede tener semanas o meses, y no tiene sentido montar encima algo con agujeros conocidos. Después dejo activadas las actualizaciones automáticas de seguridad y, una vez al mes, reviso a mano las demás y reinicio si hace falta.

La otra protección que añado es contra los intentos repetidos. Uso fail2ban, un programa que vigila los registros y, cuando una misma dirección falla varias veces seguidas al intentar entrar, la bloquea durante un tiempo.

sudo apt update && sudo apt upgrade
sudo apt install unattended-upgrades fail2ban
sudo ufw default deny incoming
sudo ufw allow PUERTO/tcp        # el del acceso remoto, antes de encender
sudo ufw allow 80/tcp && sudo ufw allow 443/tcp   # solo si sirve web
sudo ufw enable && sudo ufw status verbose
sudo fail2ban-client status sshd

Ojo al orden: si enciendes el cortafuegos antes de abrir tu puerto, te quedas fuera.

Las copias las configuro antes de que haya nada que copiar. Si lo dejo para cuando haya algo importante, ya no me acuerdo, y el día que las necesitas llega antes de lo previsto.

Tengo dos capas. La primera son las copias automáticas del proveedor, que guardan la máquina entera cada noche y conservan unos días. La segunda es una copia diaria de los datos y la configuración hacia uno de los servidores de la red interna, de madrugada. Si en casa se va la luz una semana, la del proveedor sigue ahí. Pero esas dos capas no son del todo independientes: la copia del proveedor vive con la máquina y con la misma cuenta, y si la cuenta o la plataforma fallan, se van juntas.

La regla clásica es la 3-2-1: tres copias, en dos soportes distintos, una fuera del sitio principal. Para acercarme, desde este verano la copia de casa se duplica una vez por semana a un disco externo que solo conecto para eso.

Luego está la prueba que casi nadie hace: restaurar. Una copia que nunca has restaurado es una esperanza, no una copia. La hice por primera vez en marzo de 2025, levantando una máquina nueva a partir de la copia de otra. Funcionó, pero descubrí que me faltaba un fichero de configuración que no estaba en la lista de lo que se copiaba. Lo añadí esa misma tarde. Desde entonces hago una restauración de prueba al mes: levanto un VPS temporal, vuelco la copia, compruebo que el servicio arranca y responde, y lo borro.

Cuando la casa está cerrada, instalo lo básico que va en todas las máquinas, antes de lo específico de cada una:

• Un agente de monitorización, para ver memoria, disco y procesador sin tener que entrar.
• El cliente del túnel que la conecta con la red interna.
• Docker, porque casi todo lo que corro después va en contenedores y así lo aparto del sistema.
• Lo necesario para los agentes: el entorno para ejecutar sus herramientas y las variables con las claves de las API, guardadas fuera del código.

En todo esto me acompaña Claude. Le digo qué sistema tengo y qué quiero hacer, y me guía paso a paso. También le paso la configuración para que la revise en busca de algo abierto de más. Lo que no le dejo es hacerlo solo: no le doy acceso libre a una máquina recién creada para que la configure mientras yo tomo café. Cada orden que toca la seguridad la leo, la entiendo y la ejecuto yo.

El primero fue dejar la seguridad para luego. En el primer VPS instalé el servicio que necesitaba y pensé que ya me encargaría del resto el fin de semana. No pasó nada grave, pero cuando miré los registros había miles de intentos de entrada con contraseña en tres días. Me dio tal susto que la borré y empecé de cero. Coste: una tarde perdida y un buen rato de sudor frío.

El segundo, un puerto abierto que no debía. Dejé a la vista el panel de administración de una base de datos «solo para probar». Lo encontré abierto dos semanas después, sin que nadie hubiera entrado, que yo sepa. No me costó dinero; me costó la tranquilidad de no saberlo con certeza.

El tercero, una máquina sin copias. Un VPS de pruebas que se convirtió en importante sin avisar. Cuando se corrompió el disco, perdí unas seis horas rehaciendo la configuración a mano.

¿Y cuánto se tarda? La primera vez me llevó casi un día entero, entre leer, equivocarme y volver a empezar. Hoy, con la lista y la ayuda del asistente, una máquina queda lista en poco más de una hora; es lo que marcó el reloj en las tres últimas que monté. Son tiempos míos, no una referencia: dependen de lo que lleve cada máquina.

Una advertencia que no es exagerada: una máquina recién creada con dirección pública empieza a recibir intentos de acceso automáticos muy pronto.

En el último VPS que monté, dejé los registros sin filtrar durante las primeras horas para verlo con mis propios ojos. El primer intento llegó a los veinte minutos de encender la máquina. En las primeras veinticuatro horas conté más de mil doscientos intentos de entrada, casi todos probando el usuario administrador y contraseñas de manual. Los conté en el registro de autenticación, con el puerto por defecto todavía abierto; al cambiarlo bajaron a unas decenas al día. Es lo que vi en una máquina concreta, no una estadística. Ninguno entró, porque ya no había contraseñas que adivinar. Pero ver esa lista cambia la forma de entender el «ya lo haré luego».

Esta es la lista que repaso en cada máquina nueva:

• Proveedor y tamaño elegidos según la función
• Usuario propio creado, administrador directo desactivado
• Acceso solo con claves, contraseñas desactivadas
• Cortafuegos activo, solo lo imprescindible abierto
• Sistema actualizado y actualizaciones de seguridad automáticas
• Protección contra intentos repetidos
• Copias programadas, una de ellas fuera del proveedor, y una restauración probada
• Instalación base: monitorización, túnel, contenedores

Cópiala y hazla tuya; lo importante es seguirla siempre en el mismo orden. Qué sistema lleva cada máquina y por qué lo cuento en Linux o Windows en mis servidores.