Més enllà de l'etiqueta de versió, OpenSSH 10.1 consolida el camí iniciat amb la sèrie 10: migració cap a criptografia post-quàntica, modernització de QoS amb DSCP, i enduriment d'àrees històricament sensibles (agents, claus, registres i parsing de paràmetres). A continuació trobaràs un repàs minuciós de totes les novetats (amb context on aporta valor), a més de pautes pràctiques per adoptar-les sense sorpreses.
El que segueix és la llista amb les novetats d'aquesta versió, disponibles també a les notes oficials.
Novetats destacades i context de la versió
La publicació oficial d'OpenSSH 10.1 (2025‑10‑06) subratlla tres eixos: seguretat preventiva davant de criptografia quàntica, xarxes amb DSCP i sanejament d'entrades. Connecta també canvis puntuals de gran impacte operatiu: des de rutes de sockets de l'agent fins a nous senyals de diagnòstic.
Un recordatori clau del projecte: una futura versió ignorarà els registres SSHFP basats en SHA‑1, Mentre que ssh-keygen -r ja genera empremtes SSHFP només amb SHA‑256 per defecte, tancant la porta a hash febles per a la verificació de DNSSEC i de la clau de l'amfitrió.
Avís per criptografia no post-quàntica i nova opció WarnWeakCrypto
OpenSSH 10.1 introdueix un avís quan la connexió negocia un intercanvi de claus que no és resistent a atacs post-quàntics. L'objectiu és posar focus en el risc d''store now, decrypt later' (emmagatzemar ara, desxifrar després) i accelerar la transició en entorns sensibles.
Aquest comportament es controla amb WarnWeakCrypto (en ssh_config), que ve activat per defecte. Si estàs en una migració gradual o mantens hosts legacy, pots desactivar l'avís de manera selectiva amb blocs Match. Per exemple:
Match host unsafe.example.com WarnWeakCrypto no
Criptografia i estat de l'art: PQC, híbrids i SSHFP
A la versió 10.0, el client va canviar a utilitzar per defecte mlkem768x25519‑sha256, un algoritme híbrid postquantic que combina ML‑KEM (KEM NIST FIPS 203) amb X25519. Aquesta estratègia híbrida garanteix que, fins i tot si sorgís un avenç criptoanalític a la part PQ, no estaries pitjor que amb ECDH clàssic perquè el canal conserva la força de X25519.
Amb 10.1, a més de l'avís explicat abans, es reforça la transició: OpenSSH continuarà ignorant en el futur SSHFP amb SHA‑1; l'eina ssh-keygen ja emet SSHFP amb SHA‑256 exclusivament. En termes operatius, l'acció recomanada és regenerar i publicar empremtes SSHFP a SHA‑256 per als teus hosts.
Preguntes habituals: per què insistir ara si els ordinadors quàntics encara no poden trencar SSH? Perquè els atacants poden capturar avui i desxifrar demà. Usar KEX post-quàntic ja mitiga aquest vector. I si t'inquieta la joventut dels algorismes PQ, recorda que la modalitat híbrida manté el nivell de seguretat clàssic com a base.
Modernització de xarxa: DSCP/IPQoS i priorització de trànsit
Aquesta versió consolida una revisió profunda de QoS. En client i servidor, el trànsit interactiu adopta per defecte la classe EF (Expedited Forwarding), la qual cosa ajuda a reduir latències a Wi‑Fi i mitjans congestionats. El trànsit no interactiu passa a fer servir la marca DSCP per defecte del sistema, sense elevar prioritat.
A la pràctica, tant ssh(1) com sshd(8) canvien dinàmicament la marca emprada segons el tipus de canals presents: si una mateixa connexió combina un shell i un sftp, la fase de transferència no interactiva utilitzarà el valor no interactiu durant l'operació i tornarà a EF quan correspongui. Això es controla mitjançant la clau IPQoS en ssh_config y sshd_config.
A més, es retira el suport dels antics ToS d'IPv4 a l'opció IPQoS (lowdelay, throughput, reliability deixen de tenir efecte). Si encara els feies servir, migra a nomenclatura DSCP (P. Ex., ef, cs0, af11, Etc).
Enduriment d'entrades: usuaris, URIs i expansions
A l'apartat de seguretat, 10.1 corregeix un cas subtil on, si construïes línies d'ordre amb dades externes i alhora usaves ProxyCommand amb expansions tipus %r/%u, un atacant podia colar expressions de shell. Per mitigar-ho, ssh(1) ara prohibeix caràcters de control en usuaris passats per CLI o expandits, i també bloqueja el caràcter nul en els URI ssh://.
Nota de compatibilitat: s'ha relaxat un punt de validació per tal de no trencar casos legítims. Els noms dusuari literals definits en fitxers de configuració (sense expansions %) queden exempts, sobre la base que el config local es considera de confiança.
Senyals i informació en viu: SIGINFO i visibilitat
Un altre avenç pràctic per a depuració: ssh(1) i sshd(8) guanyen manejadors SIGINFO que registren l'estat de canals i sessions actives. En producció, això facilita diagnòstics de fluxos, multiplexació, reenviaments i X11 sense necessitat adjuntar un depurador o elevar verbositat de forma invasiva.
A la mateixa línia de transparència, quan una autenticació amb certificat falla, sshd ara registra prou informació per identificar el certificat (a més de per què s'ha denegat). Si treballeu amb PKI i certificats d'usuari/host, aquesta millora escurça moltíssim els temps de resolució.
ssh‑agent i claus: sockets, neteja i PKCS#11
Per evitar accessos creuats en entorns amb muntatge restringit de /tmp, els sockets de l'agent (i els reenviats per sshd) es mouen de /tmp a ~/.ssh/agent. Així, un procés amb permisos limitats sobre /tmp ja no hereta per accident la possibilitat de signar amb les claus de l'agent.
Aquest canvi té una altra derivada: abans el SO podia netejar sockets obsolets, ara ssh‑agent incorpora la seva pròpia neteja de sockets antics. A més, l'agent suma noves banderes: -U y -u per controlar neteja en arrencar, -uu per ignorar hostname en neteja, i -T per forçar la ubicació històrica a /tmp si de debò la necessites.
Al plànol de claus, el client i l'agent ja suporten ed25519 allotjades a tokens PKCS#11. Si depens de HSM o claus criptogràfiques, guanyaràs flexibilitat sense cedir fortalesa.
ssh‑add i certificats: caducitat autonetejable
Quan afegiu certificats a l'agent, ara es fixa la seva expiració amb una gràcia de 5 minuts. La idea és simple: permetre finalitzar transaccions en cua i, tot seguit, eliminar el certificat de l'agent automàticament. Si el teu flux exigeix control total, ssh‑add -N desactiva aquest comportament.
RefuseConnection: talls controlats des del costat client
Hi ha escenaris on t'interessa avortar una connexió des del client amb un missatge clar (per exemple, redireccions operatives o avisos de deprecació). OpenSSH 10.1 afegeix RefuseConnection a ssh_config: si es troba mentre es processa una secció activa, el client acaba amb error i mostra el text que heu definit.
Qualitat del codi i seguretat viva
L'equip continua amb el sanejament del codi base. A 10.1 es llisten fuites de memòria tallades, millores d'atomia en escriure known_hosts a alta concurrència i diverses condicions de carrera resoltes en processos com MaxStartups o sessions X11.
Un apunt de neteja cripte: s'elimina el suport per a XMSS (experimental i mai per defecte). Preparant el terreny per esquemes de signatura postquantics més madurs que arribaran a futures versions.
Portabilitat i ecosistema: PAM, FreeBSD, macOS, Android…
Els canvis de portabilitat toquen molts fronts: comprovacions extra en entorns PAM (com assegurar que l'usuari no canvia durant el procés), millores d'integració amb FreeBSD (tun forwarding i compatibilitat), macOS (detecció robusta de funcions i headers) i Android (struct passwd amb camps no nuls).
També s'hi afegeixen capçaleres de compatibilitat per a plataformes sense certes biblioteques estàndard, reduint el nombre de #ifdef dispersos. Finalment, s'afinen polítiques de sandbox seccomp a Linux per cobrir syscalls com futex_time64 en 32-bit, i se suma suport a AWS‑LC com a alternativa a OpenSSL/LliureSSL.
QoS en acció: exemples pràctics i migració d'IPQoS
Si feu servir els antics àlies ToS (lowdelay, throughput...), ara seran ignorats i veureu un missatge de depuració suggerint DSCP. La migració típica seria passar de IPQoS lowdelay a IPQoS ef per a sessions interactives; si a més fas SFTP pesat, podries definir perfils per Match en ssh_config/sshd_config per separar trànsit.
Recorda que el motor selecciona i actualitza automàticament la marca en temps real segons els canals oberts, de manera que la major part de la feina ja ho fa OpenSSH per tu.
Instal·lació d'OpenSSH 10.1 a Linux (font)
Mentre les distribucions integren la versió, pots compilar des de la font oficial. Descarrega el tarball des dels mirrors del projecte, descomprimeix i compila:
tar -xvf openssh-10.1.tar.gz
Entra al directori i configura prefixos i rutes de configuració si ho necessites. Per exemple:
cd openssh-10.1 ./configure --prefix=/opt --sysconfdir=/etc/ssh
Compila i instal·la com de costum (segons permisos, potser amb superusuari):
fer
make install
Habilitar OpenSSH a Windows amb PowerShell
En entorns Windows moderns (Server 2019/Windows 10 1809+), pots instal·lar el client i servidor OpenSSH com a característiques del sistema. Comprova capacitats i estat:
Get-WindowsCapability -Online | Where-Object Name -like 'OpenSSH*'
Instal·la els components segons necessitis:
Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0 Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
Arrenca i habilita el servei del servidor SSH, i verifica la regla de tallafocs d'entrada:
Start-Service sshd Set-Service -Name sshd -StartupType 'Automatic' Get-NetFirewallRule -Name 'OpenSSH-Server-In-TCP' -ErrorAction SilentlyContinue
Per connectar-te des d'un altre host Windows o Linux, fes servir el client estàndard: ssh dominio\usuario@servidor. Al primer accés, accepta la petjada del host i autentica't amb el teu password o clau.
Guia operativa: diagnòstics i bones pràctiques
Per a entorns amb certificats d'usuari/host, aprofita el logging millorat de denegacions a sshd per depurar CA i extensions. Si una sessió s'encalla o sospites de multiplexació, llança SIGINFO al procés per llistar canals actius sense pujar el nivell global de logs.
Si depens d'agents, revisa on viuen els sockets ara (~/.ssh/agent) I activa neteja automàtica al teu model de desplegament. En estacions compartides o NFS, considera la bandera de l'agent per establir hash de hostname a la ruta quan calgui.
Errors corregits més rellevants
A 10.1 se solucionen regressions menors a X11 quan es combinava amb mitigacions de pulsacions (ObscureKeystrokeTiming), un cas de mala comptabilitat de MaxStartups que podia negar slots, i l'escriptura de known_hosts ara es fa en operacions atòmiques per evitar línies intercalades amb alta concurrència.
Altres fixes milloren diagnòstics en carregar claus, el tractament de límits de mida de config (de 256KB a 4MB), la sortida d'auditoria i corner cases exòtics en reenviaments locals i seqüències de control. A més, es posen al dia missatges i sortides de ssh -G y sshd -T.
Checklist de migració recomanada
Aquesta llista ràpida recull les tasques que el propi projecte suggereix i allò que es desprèn dels canvis:
- cripto: verifica que el teu
KexAlgorithmspermet híbrids PQ i genera noves SSHFP a SHA‑256 ambssh-keygen -r. - QoS: revisa
IPQoSen client/servidor; migra ToS legacy a DSCP; aprofita EF per a sessions interactives. - Agents: adapta scripts i variables a sockets baix
~/.ssh/agent; valora neteja automàtica del propi agent. - Configs grans: si generes configs massives, el límit puja a 4MB; aplica-ho amb cap i controla la validació.
- Analitzadors: evita construir línies d'ordre des d'inputs no fiables; utilitza
configlocals amb literals quan tinguis casos estranys a usernames.
Qui administri flotes mixtes agrairà que 10.1 premeu la seguretat on fa menys mal (parsers, agents, advertiments) i alhora milloreu l'experiència diària (QoS dinàmica, SIGINFO, registre de certificats). Si ja teníeu la versió 10.0, la transició és senzilla; si veniu de la versió 9.x, preneu-vos el temps d'ajustar DSCP, regenerar SSHFP a SHA-256 i habilitar els KEX híbrids per protegir-vos de l'amenaça quàntica sense sacrificar el rendiment.
