Lo que publica OpenSSH 10.6, y lo que no dice
OpenSSH 10.6, y su versión portable 10.6p1 que usan las distribuciones Linux, se publicó el 6 de octubre de 2026. Las notas de versión anuncian «varias correcciones de seguridad», algunas novedades y pequeñas correcciones de errores. No enumeran ningún identificador CVE ni mencionan explotación activa: esta guía se ciñe estrictamente a lo que dicen.
El equipo de OpenSSH añade una precisión que importa a quien administra un parque. Recibe gran cantidad de informes elaborados con herramientas de IA, ha constatado que varios errores fueron descubiertos de forma independiente por investigadores distintos, y concluye que los atacantes también pueden encontrarlos. Por eso anuncia publicaciones más frecuentes, para entregar las correcciones antes en lugar de agruparlas.
Para una agencia, la consecuencia es concreta: actualizar OpenSSH ya no es un acontecimiento anual. Necesita un procedimiento que se repita sin riesgo, servidor tras servidor, y que le diga cada vez qué ha cambiado realmente.
Las correcciones de seguridad de la 10.6, tal como se enumeran
- sftp — el cliente valida con más rigor las rutas que devuelve el servidor, para que un servidor no pueda hacer que una copia recursiva escriba fuera de su directorio de destino.
- GSSAPI —
sshdsolo conserva las credenciales GSSAPI tras una autenticación correcta, y reinicia el estado GSSAPI antes de cada intento. - Compresión — se desactiva el codificador de diccionario LZ77 para cerrar un canal lateral: un texto inyectado en un canal podía ayudar a adivinar secretos que circulaban por otro canal de la misma sesión.
- Nombres de usuario —
sshrechaza los caracteres$y\en un nombre introducido en la línea de comandos, para evitar una inyección en el shell medianteProxyCommandoMatch exec. - Certificados —
ssh-keygengestiona correctamente el horario de verano al convertir fechas; el error podía desplazar una hora la caducidad de un certificado. - Paquetes comprimidos — un contenido comprimido ya no puede superar, una vez descomprimido, el tamaño máximo de paquete.
- authorized_keys — la palabra clave
restrictse aplica ahora también al reenvío de túneles (PermitTunnel, desactivado por defecto). - Valores none — algunas opciones que aceptan
none, entre ellasAuthorizedPrincipalsFile, se leían como un nombre de archivo cuando un bloqueMatchlas redefinía.
El número mostrado no dice si está corregido
La objeción llega rápido: ninguna CVE en las notas, ninguna distribución estable entrega la 10.6, y un reinicio fallido de sshd puede dejarle fuera. ¿Por qué ocuparse ahora?
Porque las distribuciones no siguen los números del proyecto original. Conservan la versión de OpenSSH con la que salieron y le incorporan las correcciones. Ubuntu lo ha hecho: los paquetes de seguridad publicados el 14 de octubre de 2026 para las versiones 22.04, 24.04 y 26.04 incluyen las ocho correcciones enumeradas arriba, rechazo de $ y \ incluido, sin dejar 8.9p1, 9.6p1 y 10.2p1. En cambio, a 22 de octubre de 2026, el seguimiento de seguridad de Debian sigue marcando esos mismos puntos como no corregidos en Debian 12 y Debian 13, sin aviso de seguridad publicado; solo las ramas de desarrollo forky y sid entregan la 10.6p1.
Un servidor Ubuntu actualizado en 9.6p1 está por tanto mejor cubierto, en estos puntos concretos, que un servidor Debian en 10.0p1. Lo que usted comprueba es el paquete instalado y su registro de cambios. El procedimiento de comprobación y recarga, por su parte, será el mismo para cada actualización futura.
Lo que entregan las distribuciones a 22 de octubre de 2026
Desplace la tabla
| Distribución | Paquete OpenSSH | Correcciones de la 10.6 |
|---|---|---|
| Debian 12 (bookworm) | 1:9.2p1-2+deb12u10 | No incorporadas según el seguimiento de Debian |
| Debian 13 (trixie) | 1:10.0p1-7+deb13u4 | No incorporadas según el seguimiento de Debian |
| Debian forky y sid | 1:10.6p1-1 | Incluidas (versión original 10.6p1) |
| Ubuntu 22.04 LTS | 1:8.9p1-3ubuntu0.18 | Incorporadas por la actualización de seguridad |
| Ubuntu 24.04 LTS | 1:9.6p1-3ubuntu13.20 | Incorporadas por la actualización de seguridad |
| Ubuntu 26.04 LTS | 1:10.2p1-2ubuntu3.8 | Incorporadas por la actualización de seguridad |
| AlmaLinux 8 | 8.0p1 | Consultar los avisos de Red Hat y AlmaLinux |
| AlmaLinux 9 y 10 | 9.9p1 | Consultar los avisos de Red Hat y AlmaLinux |
Inventariar la versión realmente activa
Leer la versión del cliente
ssh -Vmuestra la versión del cliente OpenSSH y la de su biblioteca criptográfica, en la salida de error. Es el cliente quien aplica el control de nombres de usuario: en un puesto de administración o un bastión, es esta versión la que cuenta.Leer la versión del servidor
sudo /usr/sbin/sshd -Vmuestra la versión del demonio. La opción existe desde OpenSSH 9.2: en un servidor más antiguo, como AlmaLinux 8 en 8.0p1, no se reconoce, y hay que recurrir al gestor de paquetes.Leer el paquete instalado
En Debian y Ubuntu:
dpkg -s openssh-server | grep ^Version. En AlmaLinux y Rocky Linux:rpm -q openssh-server. Anote el número completo, sufijo de la distribución incluido: es el que compara con la tabla anterior.Buscar las correcciones en el registro del paquete
En Debian y Ubuntu:
apt changelog openssh-server | head -60. En AlmaLinux:rpm -q --changelog openssh-server | head -60. En Ubuntu, las entradasSECURITY UPDATEmencionan por ejemplo «invalid chars in command-line username» o «incorrect use of LZ77 dictionary coder».Comprobar que el servicio se ha reiniciado
Un paquete actualizado no protege nada si el demonio antiguo sigue en marcha. Compare
systemctl show -p ActiveEnterTimestamp ssh(el servicio se llamasshden AlmaLinux) con la fecha de instalación del paquete.Recorrer el parque con un solo comando
Liste sus servidores en
servidores.txt, uno por línea, y ejecute:while read -r h; do printf '%s : ' "$h"; ssh -n -o BatchMode=yes "$h" 'dpkg -s openssh-server 2>/dev/null | grep ^Version || rpm -q openssh-server'; done < servidores.txt. El resultado ocupa una línea por servidor, para ordenar por familia de sistema.
Lo que puede romperse en un parque administrado
Las notas clasifican tres puntos como cambios potencialmente incompatibles; solo uno afecta realmente a sus scripts.
El primero es el rechazo de $ y \ en un nombre de usuario introducido en la línea de comandos, tanto con usuario@host como con -l. ssh se detiene entonces con remote username contains invalid characters. Casos reales: una cuenta de dominio con la forma DOMINIO\usuario, o un script que construye el comando ssh a partir de datos externos. Un nombre escrito literalmente en la directiva User de un bloque Host no está sujeto al control; el código fuente muestra en cambio que un User construido con tokens % sí lo está. En un ProxyJump, el nombre no válido de un host de salto se rechaza con invalid username.
El segundo es la compresión: Compression yes sigue aceptándose, pero comprime peor sin el diccionario LZ77. Nada se rompe; una transferencia por un enlace lento puede simplemente tardar más. El equipo de OpenSSH recomienda comprimir en la capa de aplicación en lugar de dentro de SSH.
El tercero, la desactivación de GatewayPorts y StreamLocalForwarding, solo afecta a plataformas antiguas como QNX 6 o SCO OpenServer 5, no a sus servidores Linux. Se suman dos efectos visibles: scp -R muestra un aviso de obsolescencia, y sshd registra por defecto, con la nueva opción WarnWeakCrypto, los clientes que negocian un intercambio de claves no resistente a los ordenadores cuánticos.
Cambio, impacto, acción: la tabla de referencia
Desplace la tabla
| Cambio de la 10.6 | Impacto en un parque | Acción |
|---|---|---|
| `$` y `\` rechazados en un nombre de la línea de comandos | Scripts y cuentas `DOMINIO\usuario` que fallan | Escribir el nombre literalmente en `User` de un bloque `Host` |
| Diccionario LZ77 desactivado | `Compression yes` menos eficaz | Comprimir antes de transferir (`tar`, `rsync -z`) |
| Credenciales GSSAPI conservadas solo tras éxito | Ninguno fuera de la autenticación Kerberos | Probar un acceso Kerberos tras la actualización |
| `restrict` aplicado a los túneles | Una clave `restrict` ya no abre túneles | Inventariar las claves de servicio que dependen de `PermitTunnel` |
| Valores `none` bien leídos en `Match` | Un `AuthorizedPrincipalsFile none` por fin desactiva la opción | Revisar los bloques `Match` con `sshd -T -C` |
| `scp -R` obsoleto | Aviso en la salida de error | Quitar `-R`: la copia pasa por la máquina que ejecuta `scp` |
| `WarnWeakCrypto` activo en el servidor | Nuevas líneas en los registros de `sshd` | Localizar los clientes antiguos que actualizar |
| Horario de verano corregido en `ssh-keygen` | Caducidades de certificados antes desplazadas una hora | Revisar los certificados emitidos cerca de un cambio de hora |
Comprobar la configuración antes de recargar sshd
sshd -t comprueba la validez del archivo de configuración y de las claves, sin arrancar nada. La página de manual lo recomienda precisamente para actualizar sshd de forma fiable, ya que las opciones de configuración pueden cambiar de una versión a otra. Ninguna salida y un código de retorno 0: el archivo es legible.
sshd -T va más allá: muestra la configuración efectiva, valores por defecto incluidos. Es su fotografía de antes y después. Para comprobar un bloque Match, simule una conexión con -C, por ejemplo sudo sshd -T -C user=deploy,host=bastion.your-domain.com,addr=203.0.113.10. Las palabras clave aceptadas son user, host, addr, laddr, lport y rdomain.
El comando de recarga depende de la familia: el servicio se llama ssh en Debian y Ubuntu, sshd en AlmaLinux y Rocky Linux. Las sesiones ya abiertas sobreviven a una recarga. En Ubuntu reciente, ssh.socket escucha en lugar del demonio: cambiar Port exige systemctl daemon-reload y después reiniciar ssh.socket.
Desplegar la actualización sin perder el acceso
Mantener abierta una sesión de rescate
Abra una sesión SSH en el servidor, pase a root con
sudo -iy no la cierre hasta el final. Si la nueva configuración rechaza las conexiones, es desde ella desde donde corrige.Fotografiar la configuración efectiva
sudo sshd -T > /root/sshd-T-antes.txt. Este archivo le dirá qué ha cambiado la actualización, valor por valor.Actualizar los paquetes
Debian y Ubuntu:
sudo apt update && sudo apt install --only-upgrade openssh-server openssh-client. AlmaLinux y Rocky Linux:sudo dnf upgrade 'openssh*'.Probar la configuración
sudo sshd -t && echo OK. Si se rechaza una línea, corríjala antes que nada: un demonio que no puede leer su configuración tampoco arrancará en el próximo reinicio del servidor.Recargar el servicio
sudo systemctl reload sshen Debian y Ubuntu,sudo systemctl reload sshden AlmaLinux. El paquete a menudo ya ha reiniciado el servicio: recargar no cuesta nada y garantiza que la configuración leída es la correcta.Abrir una nueva conexión desde otro terminal
ssh -v [email protected]. Inicie sesión de verdad, con la clave y el usuario habituales. Mientras esta conexión no haya funcionado, la sesión de rescate sigue abierta.Comparar antes y después
sudo sshd -T | diff /root/sshd-T-antes.txt -. Una línea inesperada se resuelve ahora, no el día en que llama un cliente.Extender al parque por oleadas, a través del bastión
Primero un servidor testigo por familia de sistema, después el resto. Si sus accesos pasan por un bastión, actualícelo el último, tras comprobar sus
ProxyJump: la puesta en marcha se describe en nuestra guía del bastión SSH en VPS.
Hardening: un procedimiento, no otra checklist
Esta guía no repite el hardening de sshd_config: PasswordAuthentication no, PermitRootLogin, AllowUsers o AllowGroups y MaxAuthTries se detallan en la checklist de hardening para agencias y en el hardening inicial de un servidor Linux. Un punto sí cambia con un sshd original en 10.6: la nueva opción PubkeyOptions max-pk-ok permite a un cliente probar hasta seis claves públicas por defecto sin que esos intentos cuenten en MaxAuthTries. Un MaxAuthTries bajo deja así de rechazar al administrador que guarda muchas claves en su agente.
Solución de problemas: los mensajes que puede encontrar
Los mensajes siguientes proceden del código fuente de OpenSSH 10.6p1. Aparecen en el terminal para el cliente, y en el registro del servicio para el servidor (journalctl -u ssh o journalctl -u sshd). Lea siempre el mensaje completo antes de actuar: la mayoría señala la línea culpable.
Mensajes de error y soluciones
remote username contains invalid characters— el nombre pasado en la línea de comandos contiene$,\u otro carácter rechazado; escriba la cuenta literalmente enUserde un bloqueHost.Bad configuration option: AgentSocketPath— una opción aparecida en la 10.6 se ha copiado en un servidor que no la conoce; el mensaje cita el archivo y la línea, ysshdse detiene conterminating, 1 bad configuration options.Missing privilege separation directory: /run/sshd—sshd -tlanzado con el servicio detenido, en Debian o Ubuntu; cree el directorio consudo mkdir -p /run/sshdy repita la prueba.warning: remote/remote -R copy mode is deprecated and will soon be removed— retire-Rde sus scriptsscpantes de que una próxima versión lo ignore.invalid username— un host de salto deProxyJumplleva un nombre rechazado; traslade el nombre a un bloqueHostdedicado al bastión.- Puerto modificado ignorado en Ubuntu —
ssh.socketsigue escuchando en el puerto anterior; ejecutesudo systemctl daemon-reloady despuéssudo systemctl restart ssh.socket.
Un parque homogéneo se actualiza con un solo procedimiento
Lo que hace arriesgada una actualización de OpenSSH no es la versión: es un parque en el que cada servidor tiene su propia historia. Tres distribuciones, cuatro maneras de nombrar el servicio, scripts que pasan nombres de usuario en la línea de comandos: cada diferencia se convierte en una excepción que tratar a mano, a menudo una tarde en la que un cliente espera.
Una agencia que mantiene diez o cincuenta servidores tiene interés en reducir esas diferencias. Una misma familia de sistema, un mismo procedimiento de comprobación (sshd -t, sshd -T antes y después, sesión de rescate) y un inventario que diga con un solo comando qué paquete funciona dónde. En ServOrbit.com, el espacio para agencias reúne la cartera de sus clientes — nombres de dominio, cuentas de alojamiento, VPS — y sus vencimientos en una sola plataforma. El procedimiento de actualización, en cambio, sigue siendo suyo: esta guía lo describe tal cual, para que lo aplique en cada servidor.
