A versão OpenSSH 10.6 inclui duas mudanças de segurança que podem quebrar alguns cenários de uso anteriores: a desativação do componente LZ77 responsável por construir um dicionário de repetições na compressão SSH e a rejeição de nomes de usuário que contenham os símbolos $ e \ quando passados pela linha de comando. Os desenvolvedores do projeto tomaram a decisão cientes de que alguns ambientes e ferramentas precisarão de ajustes.
Por que a compressão SSH foi enfraquecida?
Uma única sessão SSH pode transportar um canal de terminal interativo, encaminhamento de portas ou um proxy SOCKS dinâmico. Quando a compressão estava ativada, os canais compartilhavam um único estado de compressão. Os pesquisadores Fabian Bäumer e Marcus Brinkmann, da Ruhr University Bochum, demonstraram que um atacante pode inserir um texto escolhido por ele em um canal e monitorar o tráfego criptografado para inferir dados secretos que transitam por outro canal da mesma sessão.
O ataque depende da memória LZ77, que reutiliza sequências que apareceram anteriormente em vez de codificá-las por completo. Quando uma tentativa do atacante coincide com parte do segredo, o resultado comprimido pode ficar ligeiramente menor, fornecendo um sinal que ajuda a recuperar os dados. Essa técnica pertence à família de ataques CRIME e BREACH, mas exige uma configuração específica: compressão SSH ativada, possibilidade de controlar parte do tráfego e presença do segredo e do canal sob ataque na mesma sessão SSH com múltiplos canais.
Nos testes menos ruidosos, os pesquisadores recuperaram um segredo de oito caracteres de um alfabeto de 26 caracteres com uma mediana de 276 tentativas ao longo de 100 experimentos. Em um cenário baseado em navegador e mais ruidoso, o número subiu para cerca de 27.600 tentativas. De acordo com o material de origem, os modelos de prova de conceito foram construídos usando o Claude Code.
O que muda na prática na compressão?
O OpenSSH manteve a codificação Huffman, mas desativou a parte LZ77 tanto no ssh quanto no sshd. Portanto, a compressão não desaparece completamente, mas se torna menos eficaz. O projeto afirma que as sessões interativas comuns provavelmente não notarão uma grande diferença, enquanto as tarefas automatizadas que transferem grandes quantidades de dados compressíveis por conexões de capacidade limitada podem ser afetadas.
A recomendação do OpenSSH é transferir a compressão para a camada de aplicação, onde ela costuma ser mais eficiente e não fica exposta a esse tipo de ataque. Na prática, os responsáveis por sistemas de automação que dependem da compressão SSH devem medir o volume de transferência e o tempo de execução após a atualização e, então, determinar se comprimir os dados antes do envio é mais adequado do que depender da compressão SSH.
Nomes de usuário e o fluxo de automação
A versão 10.6 rejeita os símbolos $ e \ em nomes de usuário passados pela linha de comando. Isso tem como alvo ferramentas internas, tarefas de CI e agentes que constroem um comando como ssh "$INPUT_USER@host" e cujo nome de usuário pode chegar a diretivas como ProxyCommand ou Match exec, nas quais esses símbolos podem ser interpretados como parte da construção do shell em vez de serem considerados dados comuns.
A mesma restrição não se aplica quando o nome de usuário é especificado pela diretiva User em um arquivo de configuração do SSH. Assim, contas legítimas que contenham esses símbolos ainda podem ser utilizadas dessa maneira, mas scripts e ferramentas que os passam diretamente pela linha de comando podem precisar de alterações. Isso ocorre após uma correção relacionada no OpenSSH 10.3, quando a verificação de caracteres do shell era realizada tarde demais, permitindo que eles chegassem ao caminho de expansão em ssh_config.
Mudanças adicionais que podem afetar o fluxo de trabalho
- O algoritmo de assinatura híbrida pós-quântica ssh-mldsa44-ed25519 perdeu o sufixo experimental @openssh.com, o que significa que as chaves criadas pela implementação anterior precisam ser regeneradas ou removidas.
- O projeto começou a preparar a descontinuação de scp -R para copiar de um host remoto para outro host remoto. A opção continua funcionando na versão 10.6, mas emite um aviso, e está previsto que seja ignorada no futuro.
Essas mudanças mostram que a compatibilidade com o comportamento anterior deixou de ser uma prioridade absoluta quando o uso automatizado revela um caminho para vazamento de dados ou injeção de comandos. No entanto, as limitações práticas não são iguais: o risco de vazamento pela compressão exige uma sessão e condições específicas, enquanto a rejeição de nomes de usuário pode aparecer imediatamente em scripts que dependem de entradas externas. Por isso, as equipes de operações precisam testar a atualização, revisar a construção de comandos SSH e verificar as chaves e as opções de cópia antes de adotar a versão amplamente.