🔐 SSH en Debian (1/3): el servidor sshd, usuarios y sudo

2º ASIR · Cliente SSH: MADLinuX (host) · Servidor SSH: Debian o Ubuntu (VM en VirtualBox, modo puente) Guías: 1 (esta) · RETO 1 en parejas · RETO 1 vlb36 · 2 scp y rsync (próximamente) · 3 sftp, túneles y fail2ban (próximamente)

Objetivo: convertir la VM en un servidor de verdad (sin escritorio), accesible por SSH **solo por clave cifrada 🔐 **, con dos usuarios con sudo (pepa y compa).

Cada sección tiene un camino básico (a la vista) y, a veces, un bloque 🚀 Ampliación plegado: ábrelo solo si vas sobrado.

🗺️ ¿Qué tengo que hacer, en orden? Esta guía es el paso 1, tú solo/a en tu VM:

Paso	Dónde	Con quién
1. Esta guía	servidor-ssh.md (secciones 1-8 + mini-reto + ejercicios 1-3)	tú solo/a
2. RETO 1 en parejas	/blog/reto1-ssh-compa/	tú + tu compañero/a, en el aula
3. RETO 1 vlb36	/blog/reto1-ssh-compa-vlb36/	igual, pero contra Internet (ValdeLAB36)

El 🏁 Mini-reto del punto 8 de esta guía no es el RETO 1 de verdad: es un ensayo en solitario para llegar preparado/a al paso 2.

✅ Objetivos de esta guía

Al terminar, serás capaz de:

• Dar a tu usuario permisos de sudo y arrancar la VM sin escritorio.
• Poner la VM en modo puente y averiguar su IP en la red.
• Crear un segundo usuario (compa) con sudo.
• Instalar y comprobar que sshd está escuchando.
• Conectarte por SSH y verificar la huella del servidor.
• Entrar con clave en vez de contraseña.
• Blindar el servidor: sin root, sin contraseñas, solo usuarios autorizados.

📦 Antes de empezar necesitas

• Una VM con Debian o Ubuntu instalada en VirtualBox (puede tener o no escritorio todavía).
• Tu MADLinuX (el host) con ssh instalado — ya lo tienes.
• Tu MADLinuX y la VM conectados a la misma red: el modo puente lo necesita.
• La contraseña de root de la VM (o que tu usuario ya tenga sudo, si elegiste esa opción al instalar).
• 45-60 minutos sin prisa la primera vez.

0. Escenario inicial y convenciones

  MAX: MADridLinuX (HOST)                   Debian (VM VirtualBox, en modo puente)
  ┌──────────────┐                          ┌──────────────────────┐
  │ cliente: ssh │ ───────────────────────► │ servidor: sshd (:22) │
  │ tú           │   misma red (IP propia)  │ usuarios: pepa/compa │
  └──────────────┘                          └──────────────────────┘

🟠 ¿Ubuntu en la VM? Todo funciona igual. Las pocas diferencias van marcadas con 🟠.

🧯 Kit de supervivencia en la terminal

Regla de oro del administrador de sistemas: nunca cierres tu única sesión sin haber probado otra nueva. Con una VM tienes red de seguridad extra: la consola de VirtualBox siempre entra, aunque SSH esté roto.

1. ¿Qué es SSH? (2 minutos)

SSH (Secure Shell) es un protocolo que cifra la comunicación entre dos máquinas. Sustituyó a telnet, que enviaba todo en texto plano, contraseñas incluidas.

• Servidor: sshd (paquete openssh-server), escucha en el puerto 22/tcp.
• Cliente: ssh (ya instalado en MADLinuX).

2. Punto de partida: root, tu usuario y una VM «de servidor»

Tu VM tiene dos tipos de cuenta (aquí tu usuario se llama pepa; usa el tuyo):

Como al instalar pusimos contraseña de root, Debian no le dio sudo a tu usuario. Compruébalo:

VM$ sudo whoami
# pepa is not in the sudoers file.   ← esperado: aún no tienes sudo

Arreglo: usamos root una última vez para darte sudo y, de paso, quitar el escritorio:

VM$ su -                                   # pide la contraseña de ROOT; el prompt pasa a #
VM# whoami                                 # → root
VM# apt install sudo                       # por si no estaba
VM# usermod -aG sudo pepa                  # añade pepa al grupo sudo (-a: sin quitar los demás)
VM# systemctl set-default multi-user.target   # arrancar en modo texto, sin escritorio
VM# reboot

Tras reiniciar verás una pantalla negra con debian login:. Entra con tu usuario y comprueba:

VM$ groups                       # debe aparecer: sudo
VM$ sudo whoami                  # pide TU contraseña → root

⚠️ su - con guion. Sin el guion sigues con el entorno de pepa, y verás usermod: orden no encontrada.

🤔 su o sudo:

• su -: te conviertes en root (contraseña de root) hasta que haces exit. Es peligroso olvidarse dentro.
• sudo comando: solo ese comando como root (contraseña tuya), y queda registrado quién lo hizo.

A partir de aquí usamos siempre sudo.

¿Por qué sin escritorio? Un servidor real no tiene pantalla ni ratón: está en un armario (o en la nube) y se administra a distancia, por SSH. Tener escritorio en la VM de prácticas es, como dice David, «como jugar al solitario y hacer trampas» 🙂: funciona, pero no aprendes nada.

Y lo vas a notar enseguida: en la consola de texto de VirtualBox no hay copiar y pegar, la ventana es pequeña y solo hay una. Desde la terminal de tu MADLinuX, con SSH, tendrás todo eso. Esa es la gracia de esta guía.

💡 La consola tiene 6 terminales: Ctrl derecho + F1…F6 cambia entre ellas. ¿Echas de menos el escritorio? sudo systemctl set-default graphical.target y sudo reboot (no se ha borrado nada).

🟠 Ubuntu no tiene contraseña de root y tu usuario ya tiene sudo: haz solo sudo systemctl set-default multi-user.target y sudo reboot.

3. Red: la VM en modo puente

Con Conectado a: Adaptador puente (Configuración → Red → Adaptador 1), la VM deja de estar aislada: obtiene su propia IP en tu red, como un ordenador más (igual que tu móvil o tu MADLinuX).

Enciende (o reinicia) la VM y averigua su IP:

VM$ ip -br a
# enp0s3  UP  192.168.1.57/24 ...   ← esta es la IP de tu VM (IP_VM)

Comprueba desde el HOST que se ven:

HOST$ ping -c 2 192.168.1.57          # sustituye por tu IP_VM

💡 El ping debe funcionar: la VM tiene una IP real en tu red, visible desde cualquier equipo de esa red. Si no responde, la VM no está realmente en modo puente: revisa el adaptador.

A partir de aquí, tu VM es IP_VM (por ejemplo 192.168.1.57): nada de puertos especiales, siempre el 22 por defecto. Por ejemplo: ssh pepa@192.168.1.57.

⚠️ Al estar en la misma red, tu VM es accesible para cualquiera que esté en esa red, no solo para ti. Por eso blindar el servidor (punto 8) importa de verdad.

💡 Si cambias de red (otra aula, tu casa) la IP de tu VM puede cambiar: repite ip -br a para comprobarla.

4. Usuarios: pepa (ya existe) y compa (nuevo)

VM$ id pepa                          # tu usuario: debe aparecer el grupo sudo
VM$ sudo adduser compa               # asistente: contraseña, nombre... (Enter para saltar)
VM$ sudo usermod -aG sudo compa      # compa también tendrá sudo
VM$ groups compa                     # debe aparecer: sudo

🤔 Nombres de usuario en minúsculas, sin ñ ni acentos: adduser rechaza compañero. Por eso usamos compa.

%sudo   ALL=(ALL:ALL) ALL

VM$ sudo visudo -f /etc/sudoers.d/aula
#   compa  ALL=(ALL:ALL) ALL
VM$ sudo -l -U compa                 # qué puede hacer compa

5. Instalar y comprobar sshd

Si no marcaste «servidor SSH» al instalar:

VM$ sudo apt install openssh-server

Comprobación:

VM$ systemctl status ssh             # debe poner: active (running)   (q para salir)
VM$ ss -tln | grep :22               # alguien escucha en el puerto 22

🟠 Ubuntu arranca SSH «bajo demanda» (ssh.socket): status puede decir inactive hasta la primera conexión. Lo que cuenta es que ss muestre el puerto 22.

6. Primera conexión

HOST$ ssh pepa@IP_VM
# The authenticity of host 'IP_VM' can't be established.
# ED25519 key fingerprint is SHA256:xxxxxxxx...
# Are you sure you want to continue connecting (yes/no/[fingerprint])?

Esa huella es el «DNI» del servidor. Compruébala en la consola de la VM:

VM$ ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Si coinciden, escribe yes y luego tu contraseña. Para salir de la sesión remota: exit.

⚠️ Si algún día ves WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!: o has reinstalado la VM / otra máquina ha heredado esa IP (normal) o alguien se interpone (ataque man-in-the-middle). Si es lo primero: HOST$ ssh-keygen -R IP_VM.

7. Entrar con clave en vez de contraseña

Una contraseña se puede adivinar probando millones. Con un par de claves: la privada se queda en tu máquina y la pública se copia al servidor.

HOST$ ssh-keygen -t ed25519           # Enter a todo; pon una passphrase si quieres
HOST$ ssh-copy-id pepa@IP_VM          # copia la pública (pide la contraseña, última vez)
HOST$ ssh pepa@IP_VM                  # ¡ya entra con la clave!

Host vm
    HostName IP_VM
    User pepa

HOST$ ssh vm                          # ¡sin recordar IP ni usuario!
HOST$ ssh vm 'hostname; uptime'       # ejecuta un comando y sale
HOST$ ssh -v vm                       # modo detallado: para depurar fallos

8. Blindar el servidor

No tocamos el archivo principal (/etc/ssh/sshd_config): creamos nuestro propio archivo en sshd_config.d/, que se lee antes y manda.

VM$ sudo nano /etc/ssh/sshd_config.d/10-aula.conf

PermitRootLogin no
PasswordAuthentication no
AllowUsers pepa compa

⚠️ Antes de guardar esto, comprueba que pepa y compa ya entran con clave. Si no, te quedas fuera (la consola de VirtualBox te rescata).

✅ Checklist de seguridad (lo que se exige en esta guía)

• PermitRootLogin no
• PasswordAuthentication no
• AllowUsers pepa compa

Aplicar los cambios, siempre en este orden:

VM$ sudo sshd -t                        # 1) ¿sintaxis correcta? (sin mensajes = OK)
VM$ sudo systemctl reload ssh           # 2) recargar (no corta la sesión abierta)
HOST$ ssh pepa@IP_VM                    # 3) probar en OTRA terminal, sin cerrar la actual

MaxAuthTries 3              # intentos por conexión
LoginGraceTime 30           # segundos para autenticarse
X11Forwarding no            # sin reenvío gráfico

VM$ sudo sshd -T | grep -i passwordauthentication   # valor REAL activo
VM$ sudo journalctl -u ssh -f                       # log en vivo (Ctrl+C para salir)

🏁 Mini-reto (ensayo en solitario): dar acceso SSH a compa

ℹ️ Esto no es el RETO 1 oficial (ese es en parejas, con un compañero de verdad: ver el mapa al principio de la guía). Aquí simulas tú solo/a el papel de compa para comprobar que sabes hacerlo antes de depender de otra persona.

Enunciado: compa necesita entrar por SSH a tu VM con su clave y tener sudo. Solo vosotros dos podéis entrar, sin contraseñas ni root.

1. compa existe y está en el grupo sudo.
2. compa genera su par de claves. (Simúlalo en tu HOST: ssh-keygen -t ed25519 -f ~/.ssh/id_compa.)
3. Su pública está instalada en la VM (ssh-copy-id).
4. 10-aula.conf aplicado.
5. Pruebas:

# 1) Usuario y sudo
VM$ sudo adduser compa
VM$ sudo usermod -aG sudo compa

# 2-3) Claves de compa (con las contraseñas aún activas)
HOST$ ssh-keygen -t ed25519 -f ~/.ssh/id_compa
HOST$ ssh-copy-id -i ~/.ssh/id_compa.pub compa@IP_VM

# 4) Blindar
VM$ sudo nano /etc/ssh/sshd_config.d/10-aula.conf     # (contenido del punto 8)
VM$ sudo sshd -t && sudo systemctl reload ssh

# 5) Probar (en otra terminal)
HOST$ ssh -i ~/.ssh/id_compa compa@IP_VM 'sudo whoami'   # → root
HOST$ ssh root@IP_VM                                     # → Permission denied

🏁 RETO 2: servidor sin pantalla (headless)

Enunciado: un servidor de verdad está en un armario, sin monitor. Arranca tu VM sin ventana y adminístrala solo desde MADLinuX.

1. Apaga la VM desde SSH: entra con ssh pepa@IP_VM y ejecuta sudo poweroff.
2. En VirtualBox: botón Iniciar ▾ → «Inicio sin interfaz» (Headless Start). No se abre ninguna ventana.
3. Espera unos 30 segundos (está arrancando «a ciegas») y conéctate.
4. Pruebas:

🆘 ¿No conecta? Selecciona la VM en VirtualBox y pulsa Mostrar: aparece la consola y puedes investigar (¿arrancó? ¿sshd activo? ¿cambió IP_VM?).

HOST$ VBoxManage list vms                               # nombres de tus VMs
HOST$ VBoxManage startvm "NOMBRE_VM" --type headless    # arrancar sin ventana
HOST$ VBoxManage list runningvms                        # ¿cuáles están encendidas?
HOST$ VBoxManage controlvm "NOMBRE_VM" acpipowerbutton  # apagado limpio (como pulsar el botón)

✏️ Ejercicios

1. Red. Pon la VM en modo puente y conéctate. Comprobación: ssh pepa@IP_VM y dentro, hostname.
2. Huella. Compara la huella del cliente con la de la VM. ¿Qué ataque evita esta comprobación?
3. sudo. Como compa: cat /etc/shadow → Permission denied; sudo cat /etc/shadow → funciona. Explica por qué.
4. Mini-reto completo, con la tabla de pruebas en verde.
5. RETO 2. Una sesión de clase entera con la VM en headless, sin abrir la consola ni una vez.
6. Hecho lo anterior, ya puedes empezar el RETO 1 en parejas (ver el mapa al principio de la guía): no forma parte de esta lista, es el siguiente paso.

⚠️ Errores frecuentes

🧾 Chuleta

ssh usuario@IP_VM                      ssh-copy-id usuario@IP_VM
ssh-keygen -t ed25519                  ssh-keygen -R IP_VM
sudo adduser NOMBRE                    sudo usermod -aG sudo NOMBRE
sudo sshd -t                           sudo systemctl reload ssh
sudo systemctl set-default multi-user.target      # servidor sin escritorio
VBoxManage startvm "NOMBRE_VM" --type headless    # VM sin ventana (en el HOST)

Documentación: man ssh, man sshd_config, man sudoers.

➡️➡️ ⚠️ Esta guía es meramente informativa: puede contener errores. Por favor, si encuentras un error, hazmelo saber. ❤ Gracias

RUBRICA (BORRADOR) DE CALIFICACIÓN

Criterios de contenido (100%)

Eesta práctica se evalúa sobre todo viendo el servidor funcionar (en clase o por captura/demo), no sobre un documento entregable formal.

Escala orientativa (benévola)

• Excelente (9-10): servidor blindado y RETO 1 completo con los dos roles probados, aunque falte pulir alguna respuesta de reflexión.
• Notable (7-8.9): servidor blindado pero el RETO 1 solo se hizo en un sentido (no se cambiaron los papeles), o alguna prueba de la tabla no se verificó explícitamente.
• Suficiente (5-6.9): servidor accesible por clave pero el blindado incompleto (falta alguna de las 3 directivas), o el RETO 1 no llegó a completarse con un compañero real.
• Insuficiente (<5): no se consigue acceso por SSH con clave, o no hay ningún intento documentado del RETO 1.