Ya has usado SSH en este curso decenas de veces: entras en srv-tramontana desde portatil-alumno, copias ficheros con scp y sincronizas con rsync. Lo has usado como quien usa un ascensor, sin preguntarte cómo funciona. Esta lección abre la caja, porque SSH es la puerta principal de tu servidor y en este momento esa puerta acepta contraseñas, permite entrar como root y lleva acumulados 47 intentos fallidos desde 203.0.113.44 que nadie ha mirado.

Al terminar tendrás claves ed25519 en lugar de contraseñas, un sshd_config endurecido directiva por directiva, un ~/.ssh/config que hace el trabajo pesado por ti, túneles para llegar a la base de datos de Tramontana sin exponerla a nadie, y la costumbre —que aquí no es opcional— de no cerrar nunca la puerta por la que estás entrando.

1. Qué resuelve SSH y por qué Telnet y FTP están muertos
2. Arquitectura y las tres fases del protocolo
3. Autenticación del servidor: claves de host y known_hosts
4. Autenticación con claves: generar, instalar y proteger
5. ssh-agent, reenvío de agente y ProxyJump
6. El fichero de configuración del cliente
7. Endurecer /etc/ssh/sshd_config
8. El procedimiento seguro para no quedarte fuera
9. Túneles: local, remoto y SOCKS
10. Transferencia de ficheros: scp, sftp y rsync
11. Sesiones persistentes con tmux
12. Auditoría: los 47 intentos desde 203.0.113.44

Antes de SSH, administrar una máquina remota significaba Telnet: un protocolo que envía usuario, contraseña y todos los comandos en texto plano por la red. Cualquiera con acceso al mismo segmento —o al router de en medio— leía la sesión entera. Lo mismo con FTP, rlogin y rsh.

SSH resuelve tres problemas a la vez, y conviene distinguirlos porque cada uno se ataca de forma distinta:

La tercera es la que más se olvida y la más importante: un canal cifrado hacia el atacante equivocado no protege absolutamente nada. Por eso la lección dedica un apartado entero a known_hosts.

En srv-tramontana corre el demonio sshd, gestionado por systemd. En Ubuntu 24.04 hay un detalle que sorprende a mucha gente: el servicio está activado por socket.

ssh.socket escucha el puerto y arranca ssh.service cuando llega una conexión. La consecuencia práctica es importante y la retomamos en el apartado 7: la directiva Port de sshd_config se ignora mientras la activación por socket esté en marcha.

Una conexión SSH atraviesa tres fases en este orden:

1. Intercambio de claves y canal cifrado. Cliente y servidor negocian algoritmos y derivan una clave de sesión con Diffie-Hellman efímero. A partir de aquí todo va cifrado, incluida la fase 3.
2. Autenticación del servidor. El servidor demuestra que posee la clave privada correspondiente a su clave de host; el cliente comprueba esa clave contra known_hosts.
3. Autenticación del cliente. Ahora, y solo ahora, el usuario se identifica —con clave o con contraseña—. Es fundamental que vaya después: por eso la contraseña nunca viaja en claro.

El servidor tiene sus propias claves en /etc/ssh/, generadas en la instalación:

La primera vez que te conectas ves esto:

Qué significa de verdad ese aviso, y no lo que hace todo el mundo: SSH te está diciendo «no tengo forma de saber si esta máquina es la que buscas». La respuesta correcta no es teclear yes a ciegas, sino comparar esa huella con la que has obtenido por un canal distinto —la consola de la VM, el panel del proveedor de nube, un correo firmado de quien instaló el servidor—. Si aceptas sin comprobar, aceptas la primera máquina que responda, y ese es exactamente el hueco del ataque de intermediario (man-in-the-middle): alguien se coloca entre tú y el servidor, te presenta su clave de host, tú aceptas, y a partir de ahí descifra tu sesión, ve tu contraseña y la reenvía al servidor real. Todo con el candado verde puesto.

Tras aceptar, la clave se guarda en ~/.ssh/known_hosts y las conexiones siguientes se verifican solas. Si un día cambia, verás un aviso enorme con REMOTE HOST IDENTIFICATION HAS CHANGED! y la conexión se rechaza. Las causas legítimas son tres: se reinstaló el servidor, se regeneraron sus claves de host, o la IP se reutilizó para otra máquina. La causa ilegítima es un intermediario. Averigua cuál es antes de borrar nada, y cuando lo sepas, borra solo esa entrada:

Nunca rm ~/.ssh/known_hosts: eso destruye la confianza acumulada con todas las máquinas y te deja aceptando huellas nuevas a ciegas durante semanas.

La criptografía asimétrica usa un par de claves relacionadas matemáticamente: lo que firma la privada solo lo verifica su pública correspondiente, y de la pública no se puede deducir la privada en un tiempo razonable. En SSH, tú guardas la privada en tu portátil y subes la pública al servidor. Para autenticarte, el servidor te lanza un reto, tú lo firmas con la privada y él verifica la firma con la pública que tiene en authorized_keys. La clave privada nunca sale de tu máquina, ni siquiera cifrada: eso es lo que hace que sea radicalmente mejor que una contraseña, que sí viaja (aunque sea por un canal cifrado) y que sí se puede adivinar a fuerza de intentos.

Por qué ed25519 y no RSA: ed25519 ofrece seguridad equivalente a RSA de 3072 bits con claves de 68 caracteres, firma y verifica más rápido, no depende de un generador de números aleatorios de calidad en cada firma y no tiene parámetros que puedas elegir mal. Usa RSA de 4096 bits solo si necesitas compatibilidad con equipamiento antiguo que no soporte ed25519. El comentario -C no es decorativo: identifica de quién y de cuándo es la clave cuando revises authorized_keys dentro de dos años.

La frase de paso cifra la clave privada en disco. Es la segunda capa: si te roban el portátil, tienen un fichero inútil sin ella. El coste —teclearla en cada uso— lo resuelve ssh-agent.

Los permisos son obligatorios, no una recomendación. SSH se niega a usar una clave privada legible por otros:

Instalar la pública en el servidor, con la herramienta o a mano:

Cada línea de authorized_keys admite opciones por clave delante del tipo, y son una capa de control que casi nadie usa:

La combinación restrict,command= es la forma correcta de dar acceso a un proceso automático —una copia, un despliegue— sin darle una shell.

ssh-agent guarda tu clave descifrada en memoria para no teclear la frase de paso cada vez:

-t 4h hace que la clave caduque en el agente: si dejas el portátil desbloqueado en una cafetería, la ventana de exposición es limitada. ssh-add -D las borra todas de golpe.

El reenvío de agente (ssh -A) permite usar tus claves desde el servidor al que has entrado, para saltar a un tercero. Su riesgo real: mientras la sesión está abierta, cualquiera con root en esa máquina intermedia puede usar tu agente —hablar con el socket de /tmp/ssh-*/agent.* y firmar con tus claves para entrar en cualquier sitio donde valgan—. No te roba la clave, pero puede usarla, que a efectos prácticos es lo mismo.

La alternativa correcta es ProxyJump, que no expone el agente: el cliente abre un túnel a través del salto y negocia el cifrado de extremo a extremo con el destino final.

Regla práctica: usa ProxyJump siempre; usa -A solo si no hay alternativa, y entonces con ssh-add -c (pide confirmación en cada uso).

Todo lo anterior se escribe una vez en ~/.ssh/config (permisos 600) y desaparece de tu memoria muscular:

El multiplexado es el que más se nota: rsync y scp repetidos dejan de renegociar el cifrado cada vez.

Este es el corazón de la lección. Ubuntu 24.04 lee /etc/ssh/sshd_config y, dentro de él, un Include /etc/ssh/sshd_config.d/*.conf al principio del fichero. Como en SSH gana el primer valor encontrado, lo que pongas en un fichero de sshd_config.d/ tiene prioridad sobre el fichero principal. Esa es la forma limpia de endurecer sin tocar el original ni pelearte con la próxima actualización del paquete.

Y el debate honesto sobre cambiar el puerto: mover SSH del 22 al 2222 reduce muchísimo el ruido de los escaneos automáticos y, por tanto, el tamaño de tus logs. Lo que no hace es protegerte: cualquier nmap de diez segundos encuentra el puerto nuevo, y a cambio complicas la vida a tus herramientas y a tus compañeros. Es higiene de logs, no seguridad; no lo cuentes nunca como control. Si aun así lo haces en Ubuntu 24.04, recuerda la activación por socket: Port 2222 en sshd_config no tiene efecto y hay que tocar el socket.

La primera línea vacía borra la lista heredada; sin ella, el servicio escucharía en los dos puertos.

La regla de oro de este módulo: nunca cierres la puerta por la que estás entrando. En SSH se traduce en cinco pasos que no se saltan nunca.

sshd -t valida sintaxis; sshd -T te muestra el resultado después de resolver los Include, que es lo único que cuenta. reload relee la configuración sin tocar las sesiones establecidas: si la has liado, tus dos sesiones abiertas siguen vivas y puedes revertir. Y por encima de todo está la consola de la VM en VirtualBox, que no pasa por la red y es tu último recurso. Con activación por socket, un cambio de puerto necesita además sudo systemctl restart ssh.socket.

Un túnel SSH transporta una conexión TCP arbitraria dentro del canal cifrado. Tres formas, tres casos de uso reales en Tramontana:

Lee -L 15432:127.0.0.1:5432 así: «abre el puerto 15432 en mi máquina; lo que llegue ahí, sácalo por el otro extremo del túnel y entrégalo a 127.0.0.1:5432 visto desde el servidor». Es exactamente lo que necesitas para administrar la base de datos con una herramienta gráfica sin abrir el 5432 en el firewall. -N significa «no ejecutes ningún comando, solo el túnel».

Aviso importante: por defecto los túneles remotos (-R) solo escuchan en localhost del servidor, y eso está bien. Abrirlos a todas las interfaces requiere GatewayPorts yes en sshd_config, que es una forma estupenda de saltarte tu propio cortafuegos sin darte cuenta. Déjalo como está.

--partial conserva lo transferido si la conexión se corta, y --progress te dice si merece la pena esperar. Combinado con el ControlPersist del apartado 6, un rsync repetido ni siquiera renegocia el cifrado.

Si tu conexión se corta a mitad de un apt upgrade o de un desplegar.sh, el proceso recibe SIGHUP y muere a medias. Un despliegue interrumpido entre el rsync del release y el systemctl restart deja la aplicación en un estado que nadie diseñó.

tmux (o screen, más antiguo) mantiene la sesión en el servidor, independiente de tu conexión. Regla profesional: toda operación larga en producción se lanza dentro de tmux. Es gratis y evita incidentes de los que se cuentan durante años.

Todo lo que hace sshd acaba en el journal y en /var/log/auth.log.

lastb lee /var/log/btmp, el registro de intentos fallidos (last lee wtmp, los correctos). Con lo aprendido en el Módulo 3, el resumen por IP y por usuario probado sale en una línea:

Interpretación: 47 intentos desde una sola IP, probando root, admin, postgres y ubuntu en tres minutos. No es alguien que se equivoque de contraseña: es un bot de fuerza bruta, uno de los miles que barren Internet. Los dos intentos desde 10.0.2.77 son de la red interna y probablemente sean Luis tecleando mal.

Lo bueno: con PasswordAuthentication no acabas de convertir esos 47 intentos en ruido inofensivo, porque ya no existe la vía que estaban probando. Lo malo: el bot sigue llamando, consume recursos, ensucia tus logs y seguirá ahí mañana con otra técnica. Bloquearlo en la puerta —y automatizar el bloqueo— es exactamente el trabajo de la lección siguiente.

Advertencia de seguridad y compliance: srv-tramontana trata datos personales de huéspedes, así que el acceso remoto es un control sujeto al RGPD. En un entorno real eso implica accesos nominativos (nunca cuentas compartidas), registro de quién entra y cuándo con retención acordada, revisión periódica de authorized_keys para retirar las claves de quien ya no está, y revisión del cambio por el responsable de seguridad. Y el análisis de logs de acceso, que identifica a personas trabajadoras, tiene límites legales: se hace con finalidad de seguridad y con la política informada, no para vigilar a nadie.

• Activar PasswordAuthentication no sin haber probado la clave. El clásico que deja a gente fuera de servidores en producción. Prueba primero ssh -o PreferredAuthentications=publickey, y solo entonces recarga.
• Permisos incorrectos en ~/.ssh. SSH ignora en silencio (o casi) claves y authorized_keys demasiado abiertos. 700 el directorio, 600 las claves privadas y authorized_keys. Si algo «no funciona sin motivo», ssh -vvv te lo dice en la línea Authentications that can continue.
• Borrar known_hosts entero ante un aviso de huella cambiada. Investiga la causa y usa ssh-keygen -R <host>.
• systemctl restart ssh en vez de reload. Con configuración rota, restart te deja fuera; reload mantiene vivas las sesiones existentes.
• Copiar la clave privada a los servidores «para saltar de uno a otro». La privada no sale de tu portátil: para eso están ProxyJump y, con reservas, el agente.
• Olvidar que el grupo de AllowGroups debe existir. Si escribes AllowGroups sshusers y el grupo está vacío, no entra nadie. Créalo y añade a la gente antes de recargar.
• Consejo: documenta cada clave de authorized_keys con su comentario -C (persona, máquina, fecha) y revísalo cada trimestre. Una clave huérfana es una puerta abierta con nombre olvidado.

1. Acceso restringido para las copias. El NAS de Tramontana (10.0.2.90) debe ejecutar, y solo eso, /home/operador/scripts/respaldo_tramontana.sh --solo-lectura en el servidor. Escribe la línea exacta de authorized_keys y justifica cada opción.
2. Túnel a la base de datos. Marta quiere que Luis consulte PostgreSQL desde portatil-luis con una herramienta gráfica, sin que el 5432 quede expuesto. Da el comando, explica cada parámetro y di qué se configura en la herramienta.
3. Recuperación de un cambio desastroso. Aplicas AllowGroups admins (grupo inexistente) y recargas. Tienes una sesión SSH abierta y la consola de la VM. Detalla el diagnóstico y la reparación, y qué paso del procedimiento te habría evitado el susto.

1. Una sola línea, con doble candado —quién y desde dónde— más el confinamiento del comando:

• from="10.0.2.90" — aunque roben la clave del NAS, solo sirve desde esa IP. Es una capa extra que no cuesta nada.
• restrict — desactiva de golpe túneles, reenvío de agente, X11 y asignación de pty. Es el valor por defecto seguro: en lugar de ir prohibiendo cosas una a una, se prohíbe todo y se habilita lo necesario.
• command="..." — se ejecuta ese comando pase lo que pase; si el NAS pide bash, obtiene igualmente el script. El original queda en SSH_ORIGINAL_COMMAND, así que el script podría inspeccionarlo, pero nunca ejecutarlo a ciegas.
• El comentario final identifica la clave para la revisión trimestral.

Con esas tres opciones, un compromiso del NAS no te da una shell en srv-tramontana: da como mucho una copia de solo lectura ejecutada desde una IP concreta.

2. Un túnel local desde el portátil de Luis:

• -L 15432:127.0.0.1:5432 — abre el 15432 en portatil-luis; lo que llegue ahí sale por el túnel y se entrega a 127.0.0.1:5432 desde el punto de vista del servidor. La base de datos sigue escuchando solo en localhost.
• -N — no ejecutar ningún comando remoto: solo queremos el túnel.
• -f — pasar a segundo plano una vez autenticado, para recuperar la terminal.

En la herramienta gráfica, Luis configura host 127.0.0.1, puerto 15432, su usuario y su base de datos. Lo que protege esto: PostgreSQL no está expuesto a la red, la autenticación la controla SSH (con clave, no contraseña) y el tráfico va cifrado. Lo que no protege: si el portátil de Luis está comprometido, el atacante tiene el mismo acceso; y cualquier usuario local de ese portátil puede usar el 15432, así que la forma estricta sería -L 127.0.0.1:15432:127.0.0.1:5432.

3. Diagnóstico y reparación desde la sesión que sigue abierta (o desde la consola de la VM):

Dos reparaciones posibles, según lo que quisieras hacer:

El paso que te habría evitado el susto es el 3 del procedimiento: sudo sshd -T muestra la configuración efectiva, y comprobar getent group admins antes de recargar habría revelado en dos segundos que el grupo no existía. sshd -t no lo detecta, porque la sintaxis es perfectamente válida: el fichero está bien escrito y dice exactamente lo que no querías. Esa es la diferencia entre validar la sintaxis y validar la intención — y la razón de que la segunda sesión abierta no sea negociable.

La puerta principal de srv-tramontana ya tiene cerradura. Has entendido las tres fases del protocolo y por qué la contraseña nunca viaja en claro; sabes qué significa de verdad la huella que te piden aceptar la primera vez y cómo reaccionar cuando cambia; tienes un par ed25519 con frase de paso, un agente que la caduca a las cuatro horas y un ~/.ssh/config que multiplexa conexiones y salta con ProxyJump en vez de exponer el agente. En el servidor, un fichero en sshd_config.d/ prohíbe root, elimina la autenticación por contraseña, restringe el acceso al grupo sshusers y registra en modo VERBOSE la huella de cada clave que entra — todo aplicado con sshd -t, sshd -T, reload y tres sesiones abiertas, porque nunca se cierra la puerta por la que estás entrando. Y llegas a la base de datos por un túnel -L sin exponer un solo puerto de más.

También has puesto nombre al ruido: 47 intentos desde 203.0.113.44 probando root, admin, postgres y ubuntu en tres minutos. Contra esa IP concreta has ganado —ya no hay contraseñas que adivinar—, pero el bot sigue tocando el timbre, y mañana probará el 8080, que sigue abierto de par en par a cualquiera que llegue a la máquina, igual que lo estaría PostgreSQL si algún día escuchara fuera de localhost. SSH era un servicio; lo que falta es una política de qué puede llegar siquiera a hablar con este servidor. Eso es la lección 06-03: Firewall y Seguridad Perimetral, donde conocerás netfilter y nftables por dentro, levantarás ufw en el orden correcto para no perder la sesión, escribirás un ruleset completo para Tramontana, ajustarás los sysctl de red con impacto en seguridad y pondrás a fail2ban a bloquear automáticamente a 203.0.113.44 y a todos los que vengan detrás.