🏁 RETO 1 en parejas: tu compañero entra en tu servidor

2º ASIR · Cliente SSH: MADLinuX de tu compañero · Servidor SSH: tu VM Debian (modo puente, en la LAN del aula) Guías: 1 servidor ssh · RETO 1 en parejas (este) · 2 scp y rsync (próximamente)

Objetivo: que compa sea de verdad el compañero de al lado: entra por SSH desde su MADLinuX a tu VM, con su clave, sin que ninguna contraseña viaje por la red.

Requisito previo: tener hecha la guía 1 hasta el punto 7 (tu VM en modo texto, en modo puente, sshd funcionando y tú entrando con tu clave).

0. Escenario y convenciones

Trabajáis en parejas: A pone el servidor, B se conecta. Después, cambiáis los papeles.

  MADLinuX de B              VM de A (IP_VM_A)
  ┌─────────────┐  LAN aula  ┌─────────────┐
  │ cliente ssh │ ─────────► │ sshd  :22   │
  │ (B = compa) │            │ pepa, compa │
  └─────────────┘            └─────────────┘

⚠️ Tu VM ya era accesible para toda la red del aula desde que la pusiste en modo puente (guía 1, punto 3), no solo para ti. En este reto es la primera vez que otra persona de verdad la usa: el blindaje del punto 8 de la guía deja de ser teoría.

1. 🅰️ Confirma tu IP_VM_A

VM_A$ ip -br a                 # tu IP en la red del aula = IP_VM_A → díctasela a B

🤔 Si ya la apuntaste al hacer la guía 1, puede haber cambiado (DHCP): vuelve a comprobarla.

2. 🅰️ Preparar la cuenta compa

Si no la creaste en la guía (punto 4):

VM_A$ sudo adduser compa             # pon una contraseña cualquiera: B NO la necesitará
VM_A$ sudo usermod -aG sudo compa

3. 🅱️ Enviar tu clave pública

Usa el par de claves que ya creaste en la guía (punto 7):

HOST_B$ cat ~/.ssh/id_ed25519.pub
# ssh-ed25519 AAAAC3Nza...muy larga... b@madlinux

Envía esa línea completa a A por el chat o el correo de EducaMadrid. Es pública: no pasa nada si alguien más la ve.

⛔ Nunca envíes ~/.ssh/id_ed25519 (sin .pub): es tu clave privada. Quien la tenga, es tú.

4. 🅰️ Instalar la clave de B

Conéctate a tu VM por SSH desde tu MADLinuX (en la consola de VirtualBox no podrías pegar la clave) y ejecuta, pegando la línea que te ha enviado B:

HOST_A$ ssh pepa@IP_VM_A
VM_A$ sudo -u compa mkdir -p -m 700 /home/compa/.ssh
VM_A$ echo 'ssh-ed25519 AAAAC3Nza...PEGA-AQUÍ... b@madlinux' | sudo -u compa tee -a /home/compa/.ssh/authorized_keys
VM_A$ sudo -u compa chmod 600 /home/compa/.ssh/authorized_keys

💡 sudo -u compa ejecuta el comando como compa: así la carpeta y el archivo ya son suyos, sin tener que usar chown. La clave debe quedar en una sola línea.

5. 🅰️ Blindar el servidor

Si aún no lo hiciste, aplica el punto 8 de la guía: /etc/ssh/sshd_config.d/10-aula.conf con

PermitRootLogin no
PasswordAuthentication no
AllowUsers pepa compa

VM_A$ sudo sshd -t && sudo systemctl reload ssh

6. 🅱️ Primera conexión (¡verificad la huella!)

HOST_B$ ssh compa@IP_VM_A
# The authenticity of host 'IP_VM_A' can't be established.
# ED25519 key fingerprint is SHA256:xxxxxxxx...

Antes de escribir yes, A lee su huella en voz alta:

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

Si coincide carácter a carácter, yes. Acabáis de verificar la huella por otro canal (la voz), como hacen los administradores de verdad.

7. ✅ Pruebas (desde el MADLinuX de B)

Y desde la VM de A, mirad quién está dentro:

VM_A$ who                                    # ¿aparece compa?
VM_A$ sudo journalctl -u ssh | grep compa    # busca: Accepted publickey for compa from ...

8. 🔄 Cambiad los papeles

Ahora B pone el servidor y A se conecta. Repetid los pasos 1 a 7.

9. 🤔 Reflexión: aquí no hay nada que «cerrar»

A diferencia de una regla de reenvío de puertos, el modo puente no se «abre» ni se «cierra» para esta práctica: mientras tu VM esté encendida y en modo puente, es accesible para toda la red del aula, lo hayas usado hoy en este reto o no. Lo que de verdad te protege no es estar «escondido», es el blindaje del punto 5 (PermitRootLogin no, PasswordAuthentication no, AllowUsers).

🤔 Preguntas para reflexionar (en el cuaderno)

1. En el journalctl del paso 7, ¿desde qué IP dice la VM que entró compa? Compárala con la IP real del MADLinuX de B (ip -br a en HOST_B). ¿Coinciden? ¿Por qué es importante que coincidan de cara a bloquear a un atacante por su IP? (Lo retomaremos con fail2ban en la guía 3.)
2. ¿Por qué es más seguro que B te envíe su clave pública que decirle a B una contraseña?
3. Si la huella que lee A en voz alta no coincide con la que ve B, ¿qué podría estar pasando? ¿Qué debe hacer B?

⚠️ Errores frecuentes

# 1) A: confirmar IP_VM_A
VM_A$ ip -br a

# 2) A: cuenta compa con sudo
VM_A$ sudo adduser compa && sudo usermod -aG sudo compa

# 3) B: enviar la pública a A (chat/correo)
HOST_B$ cat ~/.ssh/id_ed25519.pub

# 4) A: instalarla (por SSH desde HOST_A, para poder pegar)
HOST_A$ ssh pepa@IP_VM_A
VM_A$ sudo -u compa mkdir -p -m 700 /home/compa/.ssh
VM_A$ echo 'ssh-ed25519 AAAA... b@madlinux' | sudo -u compa tee -a /home/compa/.ssh/authorized_keys
VM_A$ sudo -u compa chmod 600 /home/compa/.ssh/authorized_keys

# 5) A: blindar
VM_A$ sudo nano /etc/ssh/sshd_config.d/10-aula.conf    # PermitRootLogin no / PasswordAuthentication no / AllowUsers pepa compa
VM_A$ sudo sshd -t && sudo systemctl reload ssh

# 6-7) B: conectar (verificando la huella en voz alta) y probar
HOST_B$ ssh compa@IP_VM_A
HOST_B$ ssh root@IP_VM_A                      # → Permission denied

➡️ Siguiente: Guía 2: scp y rsync (próximamente)