🔐 SSH en Debian: el servidor sshd y sudo, paso a paso

1º ASIR · Cliente SSH: MADLinuX (host) · Servidor SSH: Debian o Ubuntu (VM en VirtualBox, modo puente)

Objetivo: convertir la VM en un servidor de verdad (sin escritorio), accesible por SSH con tu usuario y contraseña.

Esta es la versión sencilla: un único usuario, autenticación por contraseña, sin tocar la configuración del servidor. Es la base sobre la que luego, en 2º de ASIR, se añaden claves cifradas, un segundo usuario administrador y el blindado del servidor — eso lo veréis en la guía completa, no aquí.

✅ 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.
• Instalar y comprobar que sshd está escuchando.
• Conectarte por SSH desde tu Host y verificar la huella del servidor.

📦 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).
• 30-45 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)  │ tu usuario            │
  └──────────────┘                          └──────────────────────┘

🟠 ¿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. En esta versión sencilla entras con contraseña; blindar de verdad el servidor (sin contraseñas, sin root) lo veréis en la guía completa.

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

4. 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.

5. Primera conexión, con usuario y contraseña

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.

✏️ 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 tu usuario: cat /etc/shadow → Permission denied; sudo cat /etc/shadow → funciona. Explica por qué.
4. Averigua, sin mirar la guía completa, qué dos cosas le faltan a este servidor para considerarse “blindado” (pista: contraseñas y la cuenta root).

⚠️ Errores frecuentes

🧾 Chuleta

ssh usuario@IP_VM                      ssh-keygen -R IP_VM
sudo usermod -aG sudo NOMBRE           sudo apt install openssh-server
sudo systemctl set-default multi-user.target      # servidor sin escritorio
systemctl status ssh                   ss -tln | grep :22

Documentación: man ssh, man sshd_config.

➡️➡️ ⚠️ 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%)

Esta 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 accesible por contraseña con sudo funcionando, VM sin escritorio, todo comprobado y explicado.
• Notable (7-8.9): todo funciona con algún detalle menor sin comprobar (p.ej. huella no verificada explícitamente).
• Suficiente (5-6.9): conexión SSH lograda pero falta algún paso previo (sudo o modo puente incompleto).
• Insuficiente (<5): no se consigue acceso por SSH, o no hay ningún intento documentado.