Administrar un servidor Linux es administrar una máquina sin pantalla ni teclado, a la que le hablás por red. Eso cambia dos cosas: todo se hace por terminal, y todo lo que exponés hay que defenderlo. La conexión se hace con SSH, y la primera decisión de seguridad es usar claves en lugar de contraseña. Los programas que corren de fondo son servicios, que se gestionan con systemctl (arrancar, detener, habilitar al inicio) y cuyos registros se leen con journalctl. Se crean usuarios con privilegios acotados en vez de trabajar como administrador, y el software se instala con el gestor de paquetes de la distribución. Y el endurecimiento básico —cortafuegos, acceso solo por clave, actualizaciones al día— no es un extra: es parte de poner un servidor en marcha. Todo esto se practica en un servidor propio o en una máquina virtual.
Ver índice de contenidos
Qué cambia sin entorno gráfico
Un servidor es una máquina pensada para prestar un servicio de forma continua —una web, una base de datos, un almacenamiento— y para funcionar sin que nadie esté sentado delante. Eso tiene tres consecuencias que definen todo el trabajo:
- No hay escritorio. Ni ratón ni ventanas. Se administra por terminal, con los comandos de la guía anterior, a los que se suman los específicos de administración.
- Se accede por red. El servidor puede estar en otro edificio o en otro continente. Se entra de forma remota, y ese acceso es lo primero que hay que asegurar.
- Está expuesto. Un servidor accesible desde internet recibe intentos de intrusión automatizados desde el minuto uno. No porque alguien te eligió: porque hay programas que barren internet entera todo el tiempo.
La idea que ordena la seguridad
En un escritorio, la seguridad es sobre todo no ejecutar lo que no debés. En un servidor es distinto: cada servicio que abrís al mundo es una puerta, y cada puerta hay que decidirla y defenderla. Por eso el endurecimiento no va al final de la lista de tareas: va integrado en cada paso.
La conexión por SSH
SSH es el protocolo con el que se entra a un servidor de forma remota y cifrada. Es la herramienta que más vas a usar, y la primera que hay que configurar bien.
# Conexión básica: usuario, arroba, dirección del servidor.
ssh [email protected]
# El paso que cambia todo: autenticación por CLAVE, no por contraseña.
# 1. Generar un par de claves en TU equipo (si no lo tenés ya).
ssh-keygen -t ed25519
# 2. Copiar la clave PÚBLICA al servidor.
ssh-copy-id [email protected]
# A partir de ahí entrás sin escribir contraseña, con la clave.Una contraseña se puede adivinar por fuerza bruta, y los servidores expuestos reciben miles de intentos por día. Un par de claves no: la privada nunca sale de tu equipo, y sin ella no se entra aunque se conozca la contraseña. El endurecimiento habitual es, una vez que las claves funcionan, desactivar el acceso por contraseña por completo. Eso solo elimina de un plumazo la mayor parte de los ataques automatizados.
Servicios con systemd
Los programas que corren de fondo en un servidor —el servidor web, la base de datos, el propio SSH— son servicios. En las distribuciones principales los gestiona systemd, y el comando es systemctl.
# El estado de un servicio: si está activo, desde cuándo, y últimos registros.
systemctl status ssh
# Arrancar, detener y reiniciar.
sudo systemctl start nginx
sudo systemctl stop nginx
sudo systemctl restart nginx
# La distinción clave: "enable" hace que arranque solo al encender el servidor.
sudo systemctl enable nginx # al inicio, sí
sudo systemctl disable nginx # al inicio, noLa diferencia entre start y enable confunde al principio y es central: start lo arranca ahora; enable hace que arranque solo cada vez que el servidor se reinicie. Un servicio que iniciaste con start pero no habilitaste con enable desaparece tras el próximo reinicio, y es una causa clásica de «andaba y dejó de andar». Cuando algo falla, journalctl tiene la explicación, como se ve en la guía de diagnóstico.
Usuarios y permisos
En un servidor casi nunca se trabaja como administrador directo. Se crean usuarios con privilegios acotados y se elevan solo cuando hace falta, con sudo. Eso limita el daño de un error o de una cuenta comprometida.
# Crear un usuario y darle capacidad de administración vía sudo.
sudo adduser ana
sudo usermod -aG sudo ana # agregarlo al grupo sudo (en Debian/Ubuntu)
# Ver a qué grupos pertenece un usuario.
groups ana
# Cada servicio suele correr con SU PROPIO usuario, sin privilegios.
# Así, si ese servicio es vulnerado, el atacante no obtiene el sistema entero.El principio de fondo es el menor privilegio: cada persona y cada servicio tiene exactamente los permisos que necesita, ni uno más. Un servidor donde todo corre como administrador es un servidor donde cualquier fallo se vuelve total. La misma lógica de permisos de la guía de comandos aplica acá, multiplicada por lo que hay en juego.
Paquetes y actualizaciones
El software se instala con el gestor de paquetes de la distribución, que además resuelve las dependencias y permite actualizar todo de una vez. En la familia Debian y Ubuntu es apt:
# Actualizar la lista de paquetes disponibles y luego el sistema.
sudo apt update
sudo apt upgrade
# Instalar y quitar.
sudo apt install nginx
sudo apt remove nginx
# En la familia Red Hat/Fedora el equivalente es dnf:
# sudo dnf upgrade · sudo dnf install nginxLa ventaja del gestor de paquetes sobre bajar programas sueltos de internet es doble: el software viene de repositorios firmados de la distribución, y las actualizaciones de seguridad llegan a todo lo instalado por la misma vía. Instalar cosas por fuera de él rompe esas dos garantías, y es una fuente frecuente de problemas difíciles de rastrear. El detalle de cómo mantener el sistema al día está en actualizar el sistema operativo.
Endurecimiento básico
Un servidor accesible desde internet recibe ataques automatizados desde el momento en que está en línea. El endurecimiento mínimo son cinco medidas, y ninguna es opcional:
- Acceso por SSH con claves, sin contraseñaComo en la sección anterior. Elimina de un golpe la mayoría de los ataques de fuerza bruta.
- Cortafuegos que niega todo salvo lo necesarioPor defecto, denegar el tráfico entrante y abrir solo los puertos que el servidor usa. En Ubuntu se hace con UFW.
- Menor privilegioUsuario común elevado con sudo, y cada servicio con su propio usuario sin privilegios.
- Actualizaciones al díaAplicar las de seguridad regularmente, idealmente automatizando las críticas.
- Registros y monitoreoRevisar los registros y los intentos de acceso fallidos. Un servidor que nadie mira es uno del que nadie se entera cuando algo va mal.
# Cortafuegos en Ubuntu: denegar entrante, permitir SSH y web, activar.
sudo ufw default deny incoming
sudo ufw allow OpenSSH
sudo ufw allow 'Nginx Full'
sudo ufw enableErrores frecuentes
- Dejar el acceso por contraseña en SSH. Es la puerta de los ataques de fuerza bruta. Con claves funcionando, se desactiva.
- Trabajar siempre como administrador. Un usuario acotado con sudo limita el daño de cualquier error.
- Confundir
startconenable. Sinenable, el servicio no vuelve tras un reinicio. - No poner cortafuegos. Por defecto negar lo entrante y abrir solo lo necesario.
- Instalar software por fuera del gestor de paquetes. Se pierde la firma de los repositorios y las actualizaciones de seguridad.
- No mirar los registros nunca. Un servidor sin monitoreo esconde sus problemas hasta que son graves.
- Postergar las actualizaciones. Un servidor sin parchear acumula vulnerabilidades conocidas.
Preguntas frecuentes
¿Necesito un entorno gráfico en un servidor?
No, y de hecho conviene no tenerlo. Un servidor presta un servicio de forma continua y se administra por red, así que un escritorio gráfico solo consume memoria y procesador que deberían ir al servicio, y además agrega software que hay que mantener y asegurar sin aportar nada. Por eso las versiones de servidor de las distribuciones vienen sin entorno gráfico por defecto. Todo se hace por terminal a través de SSH, con los comandos generales del sistema más los específicos de administración. Aprender a administrar sin entorno gráfico no es una limitación: es la forma normal de trabajar con servidores.
¿Por qué usar claves SSH en lugar de contraseña?
Porque una contraseña se puede adivinar por fuerza bruta y un par de claves, en la práctica, no. Todo servidor accesible desde internet recibe miles de intentos de acceso automatizados por día que prueban contraseñas comunes; contra eso, una contraseña por buena que sea es una defensa débil. Con claves, la parte privada nunca sale de tu equipo y sin ella no se entra, sin importar cuántas contraseñas se prueben. La práctica recomendada es configurar las claves, comprobar que funcionan, y luego desactivar por completo el acceso por contraseña, lo que elimina de golpe la inmensa mayoría de esos ataques automatizados.
¿Cuál es la diferencia entre start y enable en systemctl?
Son dos acciones distintas que suelen confundirse. La orden de arrancar pone el servicio en marcha en ese momento, pero no dice nada sobre qué pasa cuando el servidor se reinicia. La orden de habilitar es la que hace que el servicio arranque automáticamente cada vez que la máquina se enciende. Por eso un servicio que solo arrancaste pero no habilitaste funciona hasta el próximo reinicio y después desaparece, lo que es una causa muy común del problema «andaba y de repente dejó de andar» tras reiniciar el servidor. En un servidor, casi siempre querés las dos cosas: arrancarlo ahora y habilitarlo para el futuro.
¿Qué es el endurecimiento y cuándo se hace?
El endurecimiento es el conjunto de medidas que reducen la superficie de ataque de un servidor: acceso por claves en lugar de contraseña, un cortafuegos que niega todo salvo lo necesario, usuarios con privilegios mínimos, actualizaciones al día y monitoreo de registros. La respuesta a cuándo se hace es clave: no al final, como un extra, sino como parte de poner el servidor en marcha. Un servidor expuesto a internet empieza a recibir ataques automatizados en cuanto está en línea, así que dejar el endurecimiento «para después» significa exponerlo justo en el momento más vulnerable. Se integra en cada paso, desde la primera conexión.
¿Por qué no instalar programas bajándolos de internet?
Porque el gestor de paquetes de la distribución ofrece dos garantías que un programa suelto no tiene. Primero, el software viene de repositorios firmados, así que hay una cadena de confianza que verifica que es lo que dice ser y no fue alterado. Segundo, todas las actualizaciones de seguridad llegan por la misma vía, de modo que mantener el sistema al día actualiza también ese software. Un programa bajado a mano rompe las dos cosas: no tenés forma sencilla de verificar su origen y queda fuera del circuito de actualizaciones, así que envejece sin que nadie lo note. Cuando algo no está en los repositorios, conviene usar los canales oficiales que el propio proyecto recomiende.
¿Dónde practico administración de servidores?
En un servidor propio o, más cómodo para empezar, en una máquina virtual en tu equipo. Instalás la versión de servidor de una distribución, sin entorno gráfico, y practicás todo el flujo: conectarte por SSH, gestionar servicios, crear usuarios, instalar paquetes y aplicar el endurecimiento, sin riesgo de afectar nada real. Muchos proveedores de nube ofrecen además servidores pequeños a bajo costo, que tienen la ventaja de estar realmente expuestos a internet y por lo tanto de enseñar de primera mano por qué el endurecimiento importa. En cualquier caso, la regla es la misma que en el resto de la categoría: se practica sobre infraestructura propia, nunca sobre servidores ajenos.
Fuentes
Documentación oficial y material de la comunidad consultados para esta guía. Fecha de consulta: 28 de julio de 2026.
Aportes de la comunidad Underc0de
- Underc0de, foro. Sección GNU/Linux. Experiencias de la comunidad administrando servidores y asegurando el acceso remoto.
- Underc0de, foro. Sección Redes. Conectividad, puertos y arquitectura, que se cruzan con la administración de un servidor.
Documentación oficial
- Canonical. Ubuntu Server documentation. La referencia de administración de un servidor Ubuntu, de la que salen las prácticas de esta guía.
- OpenSSH. OpenSSH manuals. La documentación del software de acceso remoto y de las claves.
- systemd. systemd. El sistema de arranque y de gestión de servicios usado por las distribuciones principales.
- Ubuntu. Firewalls (UFW). La configuración del cortafuegos citada en el endurecimiento.
- Debian. Securing Debian Manual. Guía de endurecimiento aplicable a toda la familia Debian.