Fedora Server en un VPS: qué es y primera hora

Qué es Fedora Server y en qué se diferencia de las otras ediciones

Fedora Server es la edición de Fedora pensada para servidores. No tiene entorno gráfico, trae firewalld y SELinux activos e incluye Cockpit, una consola de administración web. En un VPS, la primera hora consiste en actualizar el sistema y crear un usuario administrador en el grupo wheel. Después cierras el acceso por contraseña en SSH, revisas el firewall y activas las actualizaciones de seguridad automáticas. Esta guía cubre esos pasos con los comandos de dnf5, el gestor de paquetes que Fedora usa desde la versión 41.

Fedora publica varias ediciones construidas con los mismos paquetes. Lo que cambia entre ellas es qué viene instalado y cómo viene configurado.

• Workstation es el escritorio, con GNOME. En un VPS no tiene sentido, porque gasta memoria en una interfaz gráfica que nadie ve.
• Server es la edición para servidores físicos y máquinas virtuales. Se instala sin escritorio, trae Cockpit y define su propia zona de firewalld.
• Cloud (Fedora Cloud Base) es una imagen de disco ya instalada. El proveedor la arranca y la configura con cloud-init, la herramienta que en el primer arranque crea el usuario y copia tu clave SSH. Es más pequeña que Server y trae menos paquetes.
• Las imágenes de contenedor son todavía más mínimas. Sirven para ejecutar aplicaciones dentro de Docker o Podman, no para gestionar una máquina entera.

Muchos proveedores despliegan la imagen Cloud y en el panel la llaman simplemente «Fedora». Por eso conviene comprobar qué tienes en lugar de suponerlo. Si todavía estás eligiendo sistema, la comparación de qué sistema operativo elegir para tu VPS te ayuda a decidir si Fedora encaja con lo que quieres hacer.

Cómo saber qué edición de Fedora tienes en el VPS

El archivo /etc/os-release describe el sistema instalado. La línea VARIANT_ID indica la edición.

grep -E '^(NAME|VERSION_ID|VARIANT|VARIANT_ID)=' /etc/os-release

Lee el valor de VARIANT_ID. server significa Fedora Server. cloud significa la imagen Cloud Base. workstation significa el escritorio, y en un VPS sería una sorpresa. Si la línea no aparece, o muestra otro valor, tu proveedor usó una imagen propia o una imagen mínima. En ese caso no des nada por hecho: comprueba cada pieza (firewalld, SELinux, Cockpit) con los comandos de las secciones siguientes, porque una imagen mínima puede no traerlas.

VERSION_ID es el número de versión. Esta guía usa dnf5, así que vale para Fedora 41 o posterior. Las versiones anteriores usan dnf4 y ya no reciben actualizaciones, y el ciclo de vida de Fedora Server en un VPS explica cómo pasar de una versión a la siguiente sin reinstalar.

Si vienes de Ubuntu o Debian, la mayoría de las órdenes tienen un equivalente directo. La tabla de equivalencias entre comandos dnf y apt te ahorra buscar cada una por separado.

Primer paso: actualizar todo con dnf upgrade --refresh

Entra como root, o con el usuario que creó tu proveedor, y actualiza el sistema antes de tocar nada más.

dnf --version
sudo dnf upgrade --refresh

La primera orden confirma que dnf es dnf5: la salida debe mencionar dnf5. La segunda actualiza todos los paquetes. La opción --refresh obliga a dnf a descargar de nuevo los metadatos de los repositorios, que son las listas de paquetes disponibles. Sin esa opción, dnf puede usar una copia guardada en caché, y una imagen recién creada puede traer una caché de hace semanas. El comando muestra la lista de cambios y pide confirmación. Si lo ejecutas una segunda vez, debe responder que no hay nada que hacer.

Si la actualización instaló un kernel nuevo, el sistema sigue usando el antiguo hasta que reinicies. Compara el kernel en uso con los instalados:

uname -r
rpm -q kernel

Si la versión más alta de rpm -q kernel no coincide con uname -r, reinicia con sudo systemctl reboot y vuelve a entrar. En un VPS es normal que este paso tarde menos de un minuto.

Crea un usuario administrador en el grupo wheel

En Fedora, el grupo de administradores se llama wheel, no sudo como en Ubuntu. La configuración de sudo que trae Fedora incluye la línea %wheel ALL=(ALL) ALL. Esa línea permite a cualquier miembro de wheel ejecutar cualquier comando como root después de escribir su propia contraseña.

sudo useradd -m -G wheel carmen
sudo passwd carmen
id carmen

id carmen debe mostrar wheel en la lista de grupos. La contraseña es necesaria aunque luego entres por clave SSH, porque sudo te la pide a ti dentro del servidor. SSH no interviene en ese momento.

Ahora copia tu clave pública al nuevo usuario. Si entraste como root con clave, la clave está en /root/.ssh/authorized_keys. Si tu proveedor usó la imagen Cloud, lo normal es que esté en el directorio del usuario que creó cloud-init, por ejemplo /home/fedora/.ssh/authorized_keys. Ajusta la ruta de origen a tu caso.

sudo install -d -m 700 -o carmen -g carmen /home/carmen/.ssh
sudo install -m 600 -o carmen -g carmen /root/.ssh/authorized_keys /home/carmen/.ssh/authorized_keys
sudo sha256sum /root/.ssh/authorized_keys /home/carmen/.ssh/authorized_keys
sudo restorecon -Rv /home/carmen/.ssh
ls -laZ /home/carmen/.ssh

install crea el directorio y el archivo con el dueño y los permisos correctos en un solo paso. sha256sum calcula una huella de cada archivo, y los dos valores deben ser iguales: así confirmas que la copia es idéntica al original. restorecon corrige la etiqueta de SELinux. SELinux (Security-Enhanced Linux) marca cada archivo con un tipo, y la política solo deja que sshd lea las claves de un archivo con el tipo ssh_home_t. Un archivo movido con mv desde /root conserva su etiqueta de origen, admin_home_t, así que sshd no puede leerlo y el acceso por clave falla aunque los permisos sean correctos. En la salida de ls -laZ debes ver ssh_home_t en las dos líneas. Si getenforce responde Disabled, el sistema no usa etiquetas y restorecon no tiene nada que corregir.

Abre una segunda terminal en tu ordenador y prueba el usuario nuevo sin cerrar la primera:

ssh carmen@203.0.113.10
sudo whoami

Cambia 203.0.113.10 por la IP de tu VPS. Debes entrar sin contraseña de SSH, y sudo whoami debe responder root después de pedirte la contraseña de carmen. No sigas hasta que esto funcione.

Endurece SSH con un archivo en /etc/ssh/sshd_config.d/

No edites /etc/ssh/sshd_config directamente. Fedora incluye al principio de ese archivo una línea Include que carga todos los archivos .conf de /etc/ssh/sshd_config.d/. Compruébalo y mira qué archivos hay ya:

grep -n '^Include' /etc/ssh/sshd_config
ls /etc/ssh/sshd_config.d/

El orden importa. sshd lee los archivos en orden alfabético y se queda con el primer valor que encuentra para cada opción. Por eso tu archivo debe tener un número bajo. Una imagen Cloud puede traer un archivo como 50-cloud-init.conf con PasswordAuthentication yes, y un archivo 10- se lee antes y gana.

sudo tee /etc/ssh/sshd_config.d/10-endurecido.conf > /dev/null <<'EOF'
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
EOF
sudo sshd -t
sudo sshd -T | grep -Ei '^(permitrootlogin|passwordauthentication|kbdinteractiveauthentication) '
sudo systemctl reload sshd

sshd -t revisa la sintaxis. Si no imprime nada, la configuración es válida. sshd -T muestra los valores que sshd usará de verdad después de combinar todos los archivos, y las tres líneas deben terminar en no. Solo entonces recarga el servicio. En Fedora el servicio se llama sshd, no ssh.

Con estas tres opciones, root no puede entrar por SSH y nadie puede entrar con contraseña. Solo funciona una clave. Mantén abierta la sesión anterior y prueba de nuevo desde otra terminal. La guía de endurecimiento de SSH en un VPS añade más capas, como limitar usuarios o algoritmos. Si además quieres mover SSH a otro puerto, en Fedora no basta con cambiar Port: SELinux también tiene que aceptar ese puerto, y cambiar el puerto SSH con SELinux y firewalld muestra los dos pasos.

Revisa firewalld: la zona por defecto y los servicios abiertos

firewalld organiza las reglas en zonas. Una zona es un conjunto de servicios permitidos que se aplica a una o varias interfaces de red. La zona por defecto es la que recibe cualquier interfaz sin una zona asignada. Fedora Server define su propia zona, pero tu imagen puede usar otra. Comprueba qué tienes:

sudo firewall-cmd --state
sudo firewall-cmd --get-default-zone
sudo firewall-cmd --get-active-zones
sudo firewall-cmd --list-all

--state debe responder running. --get-active-zones muestra qué zona usa tu interfaz pública. --list-all muestra la zona por defecto completa, y la línea que te interesa es services: cada nombre de esa línea es un puerto abierto a internet. ssh tiene que estar ahí. Cualquier servicio que no reconozcas o no uses es un candidato a cerrar.

Si la respuesta es firewall-cmd: command not found, tu imagen no trae firewalld. Es habitual en imágenes mínimas. Instálalo y actívalo, y comprueba enseguida que ssh aparece en services desde una segunda sesión:

sudo dnf install -y firewalld
sudo systemctl enable --now firewalld
sudo firewall-cmd --list-all

Para abrir un servicio, por ejemplo un servidor web, usa --permanent y luego recarga:

sudo firewall-cmd --permanent --add-service=http --add-service=https
sudo firewall-cmd --reload
sudo firewall-cmd --list-services

firewalld guarda dos configuraciones: la de ejecución, que está activa ahora, y la permanente, que se carga al arrancar. Un cambio sin --permanent funciona al momento, pero desaparece con el siguiente --reload o reinicio. Un cambio con --permanent se escribe en disco, pero no se aplica hasta el --reload. Por eso el patrón seguro es siempre --permanent seguido de --reload.

Recuerda que muchos proveedores tienen además un firewall de red en su panel. Es independiente de firewalld, así que un puerto debe estar abierto en los dos sitios.

SELinux: comprueba que está en Enforcing y déjalo así

SELinux es un control de acceso obligatorio. Los permisos clásicos de Linux preguntan qué usuario es dueño de un archivo. SELinux pregunta además qué tipo de proceso intenta usarlo, y lo bloquea si la política no lo permite, aunque ese proceso corra como root. Comprueba el modo:

getenforce
sestatus

getenforce responde con una palabra. Enforcing significa que la política se aplica y bloquea lo no permitido. Permissive significa que solo registra lo que bloquearía, pero deja pasar todo. Disabled significa que SELinux está apagado. En un VPS con Fedora Server lo esperable es Enforcing, y conviene mantenerlo así. Su valor está en limitar el daño de un fallo: si alguien explota tu servidor web, el proceso del servidor web sigue encerrado en su tipo y no puede leer, por ejemplo, las claves SSH de los usuarios.

Un aviso para quien pruebe esta guía fuera de un VPS: dentro de un contenedor, SELinux lo gestiona el sistema anfitrión, así que getenforce puede responder algo distinto de lo que verías en una máquina virtual. Lo que cuenta es lo que responde tu VPS.

Cuando SELinux bloquea algo, el problema casi nunca se arregla apagándolo. Se arregla con la etiqueta correcta (restorecon, como hiciste con .ssh) o con un permiso explícito en la política (semanage). Las denegaciones quedan en el registro de auditoría como mensajes AVC, y sudo ausearch -m AVC -ts recent las muestra si tu sistema tiene instalado el paquete audit. Cambiar a Permissive con sudo setenforce 0 es útil solo para un diagnóstico de minutos: si el fallo desaparece, ya sabes que la causa es SELinux. Vuelve después a Enforcing con sudo setenforce 1.

Actualizaciones de seguridad automáticas con dnf5

Con dnf5 cambió el paquete. Muchas guías antiguas instalan dnf-automatic y activan dnf-automatic-install.timer, que son nombres de la época de dnf4. En dnf5 la función la da un complemento con otro nombre. Instálalo y mira qué temporizadores y archivos de configuración trae en tu sistema, en lugar de fiarte de un nombre recordado:

sudo dnf install -y dnf5-plugin-automatic
rpm -ql dnf5-plugin-automatic | grep -E 'timer$|conf$'

La lista debe incluir dnf5-automatic.timer y el archivo de valores por defecto /usr/share/dnf5/dnf5-plugins/automatic.conf. No edites ese archivo, porque una actualización del paquete lo sobrescribe. Cópialo a /etc/dnf/automatic.conf, que es donde se ponen los cambios propios de cada máquina:

sudo cp /usr/share/dnf5/dnf5-plugins/automatic.conf /etc/dnf/automatic.conf
sudoedit /etc/dnf/automatic.conf

En la sección [commands], deja estas dos opciones así:

[commands]
upgrade_type = security
apply_updates = yes

upgrade_type = security limita las actualizaciones a los paquetes con un aviso de seguridad publicado. apply_updates = yes hace que se instalen. Sin esa opción, el complemento solo descarga los paquetes y no cambia nada. Comprueba el resultado y activa el temporizador:

grep -E '^(upgrade_type|apply_updates)' /etc/dnf/automatic.conf
sudo systemctl enable --now dnf5-automatic.timer
systemctl list-timers 'dnf5-automatic*'

grep debe mostrar las dos líneas con tus valores. Si no muestra nada, las líneas siguen comentadas con # en el archivo. list-timers debe mostrar una fecha en la columna NEXT, que es la próxima ejecución. Para probarlo sin esperar, lánzalo una vez a mano y lee su registro:

sudo systemctl start dnf5-automatic.service
journalctl -u dnf5-automatic.service -n 30

El complemento no reinicia el servidor con la configuración por defecto. Un kernel nuevo, por tanto, queda instalado pero no se usa hasta que reinicies. Repite de vez en cuando la comparación entre uname -r y rpm -q kernel de la primera sección.

Cockpit: la consola web que puede venir activada

Según el proyecto Cockpit, Fedora Server lo trae instalado por defecto. Cockpit es una interfaz web para administrar el servidor: servicios, registros, almacenamiento y una terminal en el navegador. Funciona con activación por socket, lo que significa que systemd escucha en el puerto 9090 y arranca Cockpit solo cuando llega una conexión. La imagen Cloud, en cambio, no lo incluye. No hace falta que lo actives ni lo desactives ahora. Basta con saber si está expuesto: si en la salida de firewall-cmd --list-all de la sección de firewalld aparece cockpit en services, el puerto 9090 está abierto a internet y cualquiera puede ver la pantalla de acceso. Si tiene sentido dejarlo así, y qué alternativa elegir, lo analiza la comparación entre Cockpit y Webmin para administrar un servidor.

Qué falla con más frecuencia en la primera hora

sudo dice que no estás en sudoers. Ves carmen is not in the sudoers file aunque id carmen muestra wheel. La causa es que los grupos se leen al iniciar sesión, así que una sesión abierta antes de añadir el grupo no lo tiene. Sal y vuelve a entrar. Dentro de la sesión, id sin argumentos muestra los grupos que tiene de verdad.

sshd -t rechaza el archivo. Un nombre de opción mal escrito produce un mensaje como /etc/ssh/sshd_config.d/10-endurecido.conf: line 2: Bad configuration option: PasswordAuthentification. El mensaje indica el archivo y la línea. Corrige la palabra y repite sshd -t antes de recargar. Si recargas con un error, el servicio puede no volver, y por eso existe esa comprobación.

Permission denied (publickey) con el usuario nuevo. sshd rechazó la clave. En Fedora hay dos causas propias que revisar primero: la etiqueta de SELinux en .ssh (repite restorecon -Rv y comprueba ssh_home_t con ls -laZ) y los permisos, que deben ser 700 para el directorio y 600 para el archivo. La guía para resolver Permission denied (publickey) cubre el resto de causas, desde el lado del cliente.

Un puerto abierto deja de estarlo tras reiniciar. La regla se añadió sin --permanent. Compara sudo firewall-cmd --list-services con sudo firewall-cmd --permanent --list-services. Si un servicio aparece en la primera lista y no en la segunda, solo existía en la configuración de ejecución.

firewall-cmd responde FirewallD is not running. El servicio está parado o nunca se activó. sudo systemctl enable --now firewalld lo arranca y lo deja activado para los siguientes arranques. Revisa enseguida que ssh sigue en la lista de servicios.

FAQ

¿Qué diferencia hay entre Fedora Server y Fedora Cloud?

Las dos usan los mismos paquetes de Fedora. Fedora Server es una edición que se instala con el instalador y trae Cockpit, firewalld y una zona de firewall propia. Fedora Cloud Base es una imagen de disco ya instalada, más pequeña, que el proveedor configura con cloud-init en el primer arranque. La línea VARIANT_ID de /etc/os-release dice cuál tienes: server o cloud.

¿Por qué no debo desactivar SELinux en mi servidor Fedora?

Porque SELinux limita lo que puede hacer cada proceso aunque corra como root, y eso reduce el daño si un servicio es atacado. Cuando algo falla por SELinux, la solución correcta es corregir la etiqueta del archivo con restorecon o añadir el permiso con semanage. getenforce debe responder Enforcing en un VPS bien configurado.

¿Cómo activo las actualizaciones automáticas con dnf5 en Fedora?

Instala dnf5-plugin-automatic, copia /usr/share/dnf5/dnf5-plugins/automatic.conf a /etc/dnf/automatic.conf y pon upgrade_type = security y apply_updates = yes en la sección [commands]. Después ejecuta sudo systemctl enable --now dnf5-automatic.timer y comprueba la próxima ejecución con systemctl list-timers 'dnf5-automatic*'. Los nombres dnf-automatic-install.timer pertenecen a dnf4.

¿Por qué Fedora usa el grupo wheel en lugar de sudo?

Es la convención de la familia Red Hat, heredada de los sistemas Unix antiguos. La configuración de sudo de Fedora da permisos de administrador a los miembros de wheel con la línea %wheel ALL=(ALL) ALL. Añade un usuario con sudo usermod -aG wheel nombre y pide que cierre la sesión y vuelva a entrar, porque los grupos nuevos solo se cargan al iniciar sesión.