Além da versão, o OpenSSH 10.1 consolida o conjunto de melhorias da série 10 : migração para criptografia pós-quântica, modernização da QoS com DSCP e reforço de áreas historicamente sensíveis (agentes, chaves, registros e análise de parâmetros). Abaixo, você encontrará uma visão geral detalhada de todos os novos recursos (com contexto explicando seu valor), bem como orientações práticas para uma adoção tranquila.
A seguir, apresentamos a lista de novos recursos desta versão , também disponível nas notas de lançamento oficiais.
Destaques e contexto do lançamento
A versão oficial do OpenSSH 10.1 (06/10/2025) destaca três áreas principais: segurança preventiva contra criptografia quântica, redes com DSCP e sanitização de entrada . Ela também descreve mudanças operacionais significativas, que vão desde caminhos de sockets de agentes até novos sinais de diagnóstico.
Um lembrete importante do projeto: Uma versão futura ignorará os logs SSHFP baseados em SHA-1Enquanto ssh-keygen -r agora gera impressões digitais SSHFP apenas com SHA‑256 por padrão, fechando a porta para hashes fracos para DNSSEC e verificação de chave de host.
Aviso de criptografia não pós-quântica e nova opção WarnWeakCrypto
O OpenSSH 10.1 introduz um aviso quando uma conexão negocia uma troca de chaves que não é resistente a ataques pós-quânticos . O objetivo é destacar o risco de "armazenar agora, descriptografar depois" e acelerar a transição em ambientes sensíveis.
Este comportamento é controlado com AvisarWeakCrypto (No ssh_config), que é habilitado por padrão. Se você estiver fazendo uma migração gradual ou mantendo hosts legados, Você pode desativar seletivamente o aviso com blocos Match. Por exemplo:
Correspondência host unsafe.example.com WarnWeakCrypto não
Criptografia e estado da arte: PQC, híbridos e SSHFP
Na versão 10.0, o cliente passou a usar o mlkem768x25519-sha256 por padrão , um algoritmo híbrido pós-quântico que combina ML-KEM (KEM NIST FIPS 203) com X25519. Essa estratégia híbrida garante que, mesmo que ocorra uma descoberta criptoanalítica no lado PQ, você não estará em pior situação do que com o ECDH clássico, pois o canal mantém a força do X25519.
Com a versão 10.1, além do aviso explicado acima, a transição é reforçada: O OpenSSH continuará a ignorar o SSHFP com SHA‑1 no futuro.; a ferramenta ssh-keygen já emite SSHFP exclusivamente com SHA‑256. Operacionalmente, a ação recomendada é regenerar e publicar impressões digitais SSHFP em SHA‑256 para seus anfitriões.
Perguntas frequentes: Por que insistir agora se os computadores quânticos ainda não conseguem quebrar o SSH? Porque os atacantes podem capturar os dados hoje e descriptografá-los amanhã. O uso de KEX pós-quântico já mitiga esse risco. E se você está preocupado com a relativa novidade dos algoritmos PQ, lembre-se de que a abordagem híbrida mantém um alto nível de segurança clássica como base.
Modernização de rede: DSCP/IPQoS e priorização de tráfego
Esta versão consolida uma revisão completa da QoS. Tanto no cliente quanto no servidor, o tráfego interativo agora usa a classe Expedited Forwarding (EF) por padrão , o que ajuda a reduzir a latência em redes Wi-Fi e congestionadas. O tráfego não interativo agora usa o sinalizador DSCP padrão do sistema , sem elevação de prioridade.
Na prática, ambos ssh(1) e sshd(8) mudam dinamicamente a marca utilizada de acordo com o tipo de canais presentes: se a mesma conexão combina uma concha e uma sftp, a fase de transferência não interativa usará o valor não interativo durante a operação e retornará ao EF quando apropriado. Isso é controlado pela tecla IPQoS en ssh_config y sshd_config.
Além disso, O suporte para IPv4 ToS mais antigos está sendo retirado na opção IPQoS (lowdelay, throughput, reliability pararem de fazer efeito). Se você ainda os estava usando, migra para a nomenclatura DSCP (por exemplo., ef, cs0, af11, Etc.)
Proteção de entrada: usuários, URIs e expansões
Na seção de segurança, 10.1 corrige um caso sutil em que, se você construiu linhas de comando com dados externos e ao mesmo tempo usou ProxyCommand com expansões %r/%u, um invasor pode invadir expressões de shell. Para mitigar isso, ssh(1) agora proíbe caracteres de controle em usuários CLI aprovados ou expandidos, e também bloqueia o caractere nulo em URIs ssh://.
Nota de compatibilidade: Um ponto de validação foi flexibilizado para evitar problemas em casos legítimos. Nomes de usuário literais definidos em arquivos de configuração (sem expansões de %) estão isentos, visto que a configuração local é considerada confiável.
Sinais e informações ao vivo: SIGINFO e visibilidade
Outra melhoria prática para depuração: ssh(1) e sshd(8) ganham manipuladores SIGINFO que registram o status dos canais e sessões ativas. Em produção, isso facilita o diagnóstico de fluxos, multiplexação, encaminhamento e X11 sem a necessidade de anexar um depurador ou aumentar intrusivamente a verbosidade.
Seguindo a mesma linha de transparência, quando a autenticação por certificado falha, o sshd agora registra informações suficientes para identificar o certificado (além do motivo da recusa). Se você trabalha com PKI e certificados de usuário/host, essa melhoria reduz significativamente o tempo de resolução.
ssh-agent e chaves: soquetes, higienização e PKCS#11
Para evitar acesso cruzado em ambientes com montagem restrita de /tmp, os soquetes do agente (e aqueles encaminhados por sshd) self mover de /tmp para ~/.ssh/agent. Assim, um processo com permissões limitadas em /tmp não herda mais acidentalmente a capacidade de assinar com suas chaves do agente.
Essa mudança tem outra derivada: antes o SO conseguia limpar soquetes obsoletos, agora ssh‑agent incorpora sua própria limpeza de soquetes antigos. Além disso, o agente adiciona novos sinalizadores: -U y -u para controlar a limpeza na inicialização, -uu para ignorar o nome do host na limpeza e -T para forçar a localização histórica em /tmp se você realmente precisar.
No nível de chave, o cliente e o agente já suportam ed25519 hospedado em tokens PKCS#11 . Se você depende de HSMs ou chaves criptográficas, ganhará flexibilidade sem sacrificar a segurança.
ssh‑add e certificados: expiração autolimpante
Quando você adiciona certificados ao agente, Sua expiração agora é definida com um período de carência de 5 minutosA ideia é simples: permitir que as transações sejam concluídas na fila e então, excluir o certificado do agente automaticamente. Se o seu fluxo exige controle total, ssh‑add -N desabilitar esse comportamento.
RefuseConnection: desconexões controladas pelo lado do cliente
Existem cenários em que você está interessado em abortar uma conexão do próprio cliente com uma mensagem clara (por exemplo, redirecionamentos operacionais ou avisos de descontinuação). O OpenSSH 10.1 adiciona Recusar Conexão a ssh_config: se encontrado durante o processamento de uma seção ativa, o cliente encerra com um erro e exibe o texto que você definiu.
Qualidade do código e segurança ao vivo
A equipe continua a limpar a base de código. 10.1 lista vazamentos de memória corrigidos, melhorias de atomia ao escrever known_hosts com grande comparecimento e vários condições de corrida resolvidas em processos como MaxStartups ou sessões X11.
Nota sobre a limpeza da criptografia: o suporte para XMSS (experimental e nunca usado por padrão) foi removido. Isso abre caminho para esquemas de assinatura pós-quânticos mais maduros que chegarão em versões futuras.
Portabilidade e ecossistema: PAM, FreeBSD, macOS, Android…
As alterações de portabilidade abrangem várias frentes: verificações adicionais em ambientes PAM (como garantir que o usuário não seja alterado durante o processo), melhorias de integração com FreeBSD (encaminhamento e compatibilidade de tun), macOS (detecção robusta de funções e cabeçalhos) e Android (struct passwd com campos não nulos).
Cabeçalhos de compatibilidade também são adicionados para plataformas sem certas bibliotecas padrão, reduzindo o número de #ifdef dispersos. Finalmente, eles são refinados políticas de sandbox seccomp no Linux para cobrir chamadas de sistema como futex_time64 em 32 bits e o suporte é adicionado a AWS-LC como uma alternativa ao OpenSSL/LibreSSL.
QoS em ação: exemplos práticos e migração de IPQoS
Se você usou os antigos aliases do ToS (lowdelay, throughput...), agora eles serão ignorados e você verá uma mensagem de depuração sugerindo DSCP. A migração típica seria ir de IPQoS lowdelay a IPQoS ef para sessões interativas; se você também faz SFTP pesado, você pode definir perfis por correspondência en ssh_config/sshd_config para separar o tráfego.
Lembre-se de que o mecanismo seleciona e atualiza automaticamente a marca em tempo real de acordo com os canais abertos, portanto, o OpenSSH faz a maior parte do trabalho para você.
Instalando o OpenSSH 10.1 no Linux (fonte)
Enquanto as distribuições integram a versão, você pode compilar a partir do código-fonte oficial . Baixe o arquivo tarball dos espelhos do projeto, extraia-o e compile:
tar -xvf abresh-10.1.tar.gz
Insira o diretório e configure os prefixos e caminhos de configuração, se necessário. Por exemplo:
cd openssh-10.1 ./configure --prefix=/opt --sysconfdir=/etc/ssh
Compile e instale normalmente (dependendo das permissões, talvez com privilégios de superusuário):
fazer
make install
Habilitar OpenSSH no Windows com PowerShell
Em ambientes Windows modernos (Server 2019/Windows 10 1809 ou superior), você pode instalar o cliente e o servidor OpenSSH como recursos do sistema . Verifique os recursos e o status:
Get-WindowsCapability-Online | Nome do Objeto Where - como 'OpenSSH*'
Instale os componentes conforme necessário:
Adicionar-WindowsCapability -Online -Nome OpenSSH.Client~~~~0.0.1.0 Adicionar-WindowsCapability -Online -Nome OpenSSH.Server~~~~0.0.1.0
Inicie e habilite o serviço do servidor SSH e verifique a regra de firewall de entrada:
Iniciar-Serviço sshd Definir-Serviço -Nome sshd -TipoDeInicialização 'Automático' Obter-RegraDeFirewall -Nome 'OpenSSH-Server-In-TCP' -AçãoDeErroContinuarSilenciosamente
Para se conectar de outro host Windows ou Linux, use o cliente padrão: ssh dominio\usuario@servidor. No primeiro acesso, aceita a impressão digital do host e autentique-se com sua senha.
Guia operacional: diagnósticos e boas práticas
Para ambientes com certificados de usuário/host, aproveite o registro aprimorado de negações em sshd para depurar CAs e extensões. Se uma sessão travar ou você suspeitar de multiplexação, lança SIGINFO para o processo de listagem de canais ativos sem elevar o nível de log global.
Se você depende de agentes, verifique onde os soquetes estão agora (~/.ssh/agent) E ativar limpeza automática no seu modelo de implantação. Em estações de trabalho compartilhadas ou NFS, considere usar o sinalizador do agente para definir hashes de nome de host no caminho, quando necessário.
Correções de bugs mais relevantes
Em 10.1 eles são resolvidos pequenas regressões em X11 quando combinado com mitigações da frequência cardíaca (ObscureKeystrokeTiming), um caso de Má contabilidade da MaxStartups que poderia inundar slots e a escrita de known_hosts agora está feito em operações atômicas para evitar linhas intercaladas com alta simultaneidade.
Outras correções melhoram diagnósticos ao carregar chaves, tratamento de limites de tamanho de configuração (de 256 KB a 4 MB), saída de auditoria e casos extremos exóticos em encaminhamentos locais e sequências de controle. Além disso, mensagens e saídas de ssh -G y sshd -T.
Lista de verificação de migração recomendada
Esta lista rápida inclui as tarefas sugeridas pelo próprio projeto e o que surgir das mudanças:
- Cripto: verifique se o seu
KexAlgorithmspermite PQ híbrido e gera novo SSHFP em SHA‑256 comssh-keygen -r. - QoS: Confira
IPQoSno cliente/servidor; migrar ToS legados para DSCP; aproveitar o EF para sessões interativas. - Agentes: adapta scripts e variáveis para soquetes em
~/.ssh/agent; valoriza a limpeza automática pelo próprio agente. - Grandes configurações: Se você gerar configurações em massa, o limite vai até 4 MB; aplique-o com sabedoria e controla a validação.
- Analisadores: evite construir linhas de comando a partir de entradas não confiáveis; use
configlocais com literais quando você tem casos estranhos em nomes de usuários.
Quem gerencia frotas mistas apreciará o fato de que a versão 10.1 reforça a segurança onde ela é menos crítica (analisadores, agentes, avisos), ao mesmo tempo que melhora a experiência diária (QoS dinâmico, SIGINFO, registro de certificados). Se você já estava na versão 10.0, a transição é simples; se estiver migrando da versão 9.x, reserve um tempo para ajustar o DSCP, regenerar o SSHFP para SHA-256 e habilitar KEXs híbridos para se proteger contra a ameaça quântica sem sacrificar o desempenho.
