Práctica 3 — Usuarios y Red

Ejercicio 3.1 — Gestión de usuarios y sudo seguro

Contexto

En un servidor real nunca se trabaja como root directamente. Se crea un usuario específico para cada tarea y se le dan solo los permisos que necesita. En esta práctica configurarás el usuario deploy que solo podrá reiniciar nginx — nada más.

Setup — ejecutar una sola vez como alumno

# Instala nginx si no está instalado
sudo apt update && sudo apt install -y nginx

# Verifica que nginx está corriendo
sudo systemctl status nginx

Tarea 1 — Crear el usuario deploy

# Crea el usuario con su directorio home
sudo useradd -m -s /bin/bash deploy

# Establece una contraseña segura (invéntate una que recuerdes)
sudo passwd deploy
# Escribe la contraseña dos veces cuando te la pida

Tarea 2 — Configurar sudo restringido

Queremos que deploy pueda reiniciar nginx con sudo pero sin introducir contraseña y sin poder hacer ninguna otra cosa con sudo.

# Crea el archivo de configuración de sudoers para deploy
# IMPORTANTE: usa visudo o el editor con este comando para evitar errores de sintaxis
sudo nano /etc/sudoers.d/deploy

Escribe exactamente esta línea en el archivo:

deploy ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart nginx

Guarda con Ctrl+O, Enter, Ctrl+X.

Verifica que la sintaxis es correcta:

sudo visudo -c -f /etc/sudoers.d/deploy
# Debe decir: /etc/sudoers.d/deploy: parsed OK

Prueba que funciona (cambia al usuario deploy primero):

# Cambia al usuario deploy
sudo su - deploy

# Intenta reiniciar nginx (debe funcionar sin pedir contraseña)
sudo systemctl restart nginx

# Intenta listar archivos como root (DEBE FALLAR)
sudo ls /root
# Debe decir: Sorry, user deploy is not allowed to execute...

# Vuelve a tu usuario
exit

Tarea 3 — Generar par de claves SSH para deploy

La autenticación por clave SSH es mucho más segura que por contraseña. Vamos a configurarla:

# Cambia al usuario deploy
sudo su - deploy

# Genera un par de claves Ed25519 (algoritmo moderno y seguro)
ssh-keygen -t ed25519 -C "deploy@servidor-linux"
# Cuando pida la ruta, pulsa Enter para usar la predeterminada (~/.ssh/id_ed25519)
# Cuando pida passphrase, pulsa Enter dos veces (sin passphrase, para simplificar)

# Añade la clave pública al archivo authorized_keys
mkdir -p ~/.ssh
chmod 700 ~/.ssh
cp ~/.ssh/id_ed25519.pub ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

# Verifica que existen los archivos
ls -la ~/.ssh/

exit  # Vuelve a tu usuario

Tarea 4 — Proteger SSH

Edita la configuración de SSH:

sudo nano /etc/ssh/sshd_config

Asegúrate de que estas líneas existen y tienen estos valores (busca con Ctrl+W en nano si no las encuentras; si empiezan por # descoméntalas):

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin no

Aplica los cambios:

sudo systemctl reload sshd

Tarea 5 — Verificar todo junto

# Verifica los permisos de sudo de deploy
sudo -l -U deploy

# Verifica que root no puede conectarse por SSH
grep "PermitRootLogin" /etc/ssh/sshd_config

# Verifica el directorio .ssh de deploy
ls -la /home/deploy/.ssh/

Ejercicio 3.2 — Diagnóstico de red: encuentra los fallos

Contexto

Eres el sysadmin. El profesor ha “roto” el servidor de tres maneras diferentes. No sabes cuáles ni cuántas son. Tu trabajo es diagnosticar qué está fallando y solucionarlo todo.

Setup — el profesor ejecuta esto antes de darte el servidor

# (Para el profesor — no ejecutes esto tú)
sudo apt install -y nginx ufw
sudo systemctl stop nginx
sudo ufw --force enable
sudo ufw default deny incoming
sudo ufw allow ssh
echo "192.0.2.1 google.com" | sudo tee -a /etc/hosts

Síntomas que experimentarás

El servidor web no responde cuando haces curl http://localhost
Internet puede tener comportamiento extraño

Metodología de diagnóstico

Sigue siempre este orden:

Paso 1 — Comprueba si nginx responde:

curl -s -o /dev/null -w "HTTP: %{http_code}\n" http://localhost

Si no responde (error de conexión), el servidor está parado o el firewall bloquea.

Paso 2 — Comprueba si nginx está corriendo:

systemctl is-active nginx

Si dice inactive, arráncalo:

sudo systemctl start nginx

Vuelve al Paso 1. Si ahora funciona, ¿hay más problemas?

Paso 3 — Comprueba el firewall:

sudo ufw status verbose

¿Está activo? ¿Permite el puerto 80 (HTTP)?
Si no permite el 80:

sudo ufw allow 80/tcp

Paso 4 — Comprueba la resolución DNS:

ping -c 2 google.com

¿Falla o va a una IP inesperada? Inspecciona el archivo hosts:

cat /etc/hosts

¿Hay alguna línea sospechosa? Una IP como 192.0.2.X es una IP de documentación que no existe en internet.
Elimina la línea falsa:

sudo nano /etc/hosts
# Borra la línea con la IP falsa de google.com
# Guarda con Ctrl+O, Enter, Ctrl+X

Paso 5 — Verifica que todo está resuelto:

curl -s -o /dev/null -w "HTTP: %{http_code}\n" http://localhost
ping -c 2 google.com | grep "transmitted"
sudo ufw status | grep "80/tcp"

📤 Bloque de entrega

echo "=== ENTREGA PRÁCTICA 3 ===" && \
echo "" && \
echo "--- 3.1: Permisos sudo de deploy ---" && \
sudo -l -U deploy && \
echo "" && \
echo "--- 3.1: Claves SSH de deploy ---" && \
ls -la /home/deploy/.ssh/ && \
echo "" && \
echo "--- 3.1: Config SSH ---" && \
grep "PasswordAuthentication\|PermitRootLogin" /etc/ssh/sshd_config && \
echo "" && \
echo "--- 3.2: Estado nginx ---" && \
systemctl is-active nginx && \
echo "--- 3.2: Estado firewall ---" && \
sudo ufw status && \
echo "--- 3.2: DNS google ---" && \
ping -c 1 google.com | grep "transmitted"