SSH3 - um shell seguro mais rápido e mais completo usando HTTP/3

• SSH3 é um protocolo de shell seguro de próxima geração que opera sobre HTTP/3 e melhora drasticamente a velocidade de estabelecimento de sessão em comparação com o SSHv2 tradicional
• Forma um canal seguro com QUIC e TLS 1.3 e oferece suporte a sistemas modernos de autenticação, como OAuth 2.0 e OpenID Connect
• Pode ocultar o servidor atrás de um caminho secreto, tornando-o mais resistente a ataques como varredura de portas, além de oferecer novos recursos como encaminhamento de porta UDP e multipath do QUIC
• Já adotou vários recursos centrais do OpenSSH, mas ainda está em estágio experimental, portanto não é recomendável implantá-lo em ambientes reais de produção
• Como muitos consideram que o nome SSH3 não é apropriado, o rascunho de padronização foi alterado para “Remote Terminals over HTTP/3”, e a mudança de nome está em andamento

---

Visão geral e importância do projeto SSH3

• SSH3 é uma solução open source que redesenha o protocolo SSH existente para HTTP/3 e tecnologias web modernas
  • Reinterpreta a semântica do protocolo de conexão SSH existente (RFC4254) sobre HTTP/3 Extended CONNECT e canais QUIC + TLS 1.3
• Foi proposto no Internet-Draft da IETF draft-michel-remote-terminal-http3 e oferece várias vantagens, como redução significativa na velocidade de estabelecimento de sessão e expansão para métodos modernos de autenticação
• Em comparação com outras implementações de SSH, destaca-se por ideias inovadoras como o uso de QUIC e a configuração de servidor oculto

Principais recursos e características

• Estabelecimento de sessão mais rápido
  • Enquanto uma conexão SSHv2 tradicional exige em média de 5 a 7 idas e voltas de rede, o SSH3 precisa de apenas 3 idas e voltas, reduzindo bastante a latência percebida pelo usuário
  • A latência de digitação permanece em nível semelhante ao atual
• Segurança reforçada
  • Baseado em TLS1.3, QUIC e autenticação HTTP, aproveita protocolos de segurança já validados e amplamente usados em comércio eletrônico e internet banking
  • Suporta autenticação por chave pública com RSA e EdDSA/ed25519, além de vários métodos como OAuth 2.0 e OpenID Connect
  • Também permite login com contas Google, Microsoft e Github
• Recurso de ocultar o servidor
  • O servidor pode ficar atrás de uma URL secreta específica (por exemplo, https://192.0.2.0:443/M3MzkxYWMx...) e só responde quando uma solicitação de autenticação chega por essa URL
  • Para outras solicitações, retorna 404 Not Found, impedindo que atacantes e crawlers na internet detectem a existência do servidor
  • No entanto, o caminho secreto não substitui a autenticação, portanto ainda é fortemente recomendado usar um mecanismo separado de autenticação, como chave pública, senha ou OIDC
• Projeto experimental em desenvolvimento contínuo
  • Estruturalmente, ainda precisa de uma validação confiável de segurança e não é recomendável adotá-lo em servidores de produção
  • O projeto está recolhendo feedback da comunidade em ambientes de teste ou redes fechadas
• Compatibilidade com OpenSSH e recursos adicionais
  • Suporte a parsing de ~/.ssh/authorized_keys e known_hosts, integração com ssh-agent, encaminhamento de porta TCP/UDP e Proxy Jump
  • Com suporte a encaminhamento UDP, oferece acesso a servidores baseados em UDP, como serviços DNS, RTP e QUIC, usando caminho de QUIC datagram
  • Recurso de autenticação de servidor em nível de HTTPS por meio de certificados X.509
  • Autenticação sem chave (Keyless): com OpenID Connect, é possível se conectar sem copiar chave pública, usando apenas SSO corporativo ou contas externas como Google e GitHub

Conclusão

• SSH3 é um projeto open source experimental que busca evoluir o ambiente SSH ao introduzir protocolos de rede e autenticação modernos
• Ele reforça bastante velocidade, flexibilidade e segurança, mas é preciso cautela no uso em produção antes de uma validação suficiente
• Oferece uma experiência de uso semelhante à do OpenSSH e também traz muitos novos recursos
• Com uma avaliação de segurança adequada e participação da comunidade, tem potencial para se firmar como o SSH da próxima geração

[GN⁺]

Comentários do Hacker News

• Eu realmente não gostei do nome ssh3, então achei bom ver no topo do repositório algo como: “SSH3 terá o nome alterado. Por enquanto, ele ainda é o SSH Connection Protocol (RFC4254) rodando sobre HTTP/3 Extended CONNECT, mas são necessárias muitas mudanças e ele é diferente demais do SSH existente para ser integrado com facilidade. O rascunho da especificação já foi renomeado para ‘Remote Terminals over HTTP/3’, e precisamos de tempo para pensar em um nome permanente melhor”
  • Esse nome parece inadequado, como se alguém criasse um repositório chamado “Windows 12” ou “Linux 7”
  • Minha sugestão de nome, em vez de SSH3, seria algo como Secure Hypertext Interactive TTY
  • Pensei se SSH/3 não ficaria melhor (com aquela sensação de SSH + HTTP/3)
  • Esta thread é realmente uma obra-prima de discussão séria de bike-shedding
  • Talvez SSH2/3 funcionasse, já que na maioria dos casos é SSH2, mas rodando sobre HTTP/3
• SSH é lento, e na minha experiência o maior gargalo está na configuração da sessão. Seja por causa de PAM, seja por políticas do OpenBSD, tanto ao reutilizar uma conexão SSH quanto ao criar uma nova, a etapa de setup da sessão é sempre dolorosamente lenta. Em sessões longas isso tudo bem, mas até para executar um comando simples existe esse overhead toda vez, então eu nunca fiquei satisfeito com o desempenho do Ansible e acabei criando meu próprio mini-ansible para executar comandos remotos sem esse overhead de sessão
• Fiquei cético com a ideia de “isso é mesmo mais rápido que o SSH tradicional?”, mas no README diz que só a etapa de estabelecimento da conexão é mais rápida, enquanto a velocidade real depois de conectar é a mesma, então fez sentido para mim. Só isso já é uma melhoria válida
  • Na prática, ele não é mais rápido nesse sentido. Quando você encaminha tráfego de várias portas por uma única conexão SSH, acontece bloqueio de head-of-line, e protocolos como QUIC/HTTP3 podem resolver esse problema
  • Aposto que esse protocolo será muito mais rápido que SSH em links de alta latência, porque por ser baseado em UDP ele pode transmitir grandes volumes de dados continuamente sem esperar por ack, então dá para esperar um ganho considerável ao fazer scp de arquivos grandes a partir de várias partes do mundo
  • Pode ser realmente mais rápido sobre VPN, porque não cai na armadilha de “TCP dentro de TCP”
  • A principal vantagem de HTTP/3 e QUIC como um todo é reduzir round trips em relação ao que existia antes, o que combina exatamente com essa melhora no tempo de estabelecimento da conexão
• A explicação era algo como: “No SSHv2 são necessários de 5 a 7 round trips para inicializar uma sessão; no SSH3, só 3. Durante a sessão em si, a latência de entrada (tempo entre tecla e resposta) é a mesma”. Do ponto de vista do usuário, eu nunca me incomodei tanto com a velocidade de conexão, então isso não me atrai muito. SSH também tem uma estabilidade comprovada em combate, e mesmo que uma ferramenta nova como essa seja de nível de produção, ainda parece arriscado confiar nela
  • O ponto principal é o túnel UDP; além disso, ele é muito mais leve que WireGuard e ainda tem coisas como autenticação via OpenID
  • “Velocidade de conexão” sempre me incomodou um pouco. Especialmente quando quero só executar um comando remoto de imediato
  • No ssh3, há uma boa chance de o bloqueio de head-of-line ter sido resolvido, então ele deve ser mais rápido ao multiplexar várias portas ou conexões em uma mesma conexão física
  • Se você quer uma experiência de uso mais suave, recomendo o Mosh
• Não sei por que é tão triste ver todos os protocolos de camada de aplicação sendo absorvidos pelo HTTP
  • Se essa for mesmo a direção, seria triste. O modelo típico do HTTP é restritivo e complexo demais para muitos casos. Mas HTTP/2 e QUIC (o transporte do HTTP/3) são tão genéricos que o próprio nome HTTP parece perder muito do sentido. Pelo menos o QUIC está sendo posicionado com bastante clareza como substituto do TCP
  • Na verdade, vejo isso até de forma positiva, porque quando todos os protocolos acabam padronizados, fica mais difícil fazer traffic shaping, censura etc. No fim das contas, se o tráfego é HTTP ou um fluxo de bytes aleatório (ou seja, não chama atenção), fica mais difícil monitorar ou bloquear na rede. Se você vai criar um protocolo novo, a menos que a operadora tenha algum motivo especial para tratá-lo melhor, disfarçá-lo como HTTP costuma ser a forma de fazê-lo trafegar sem lentidão nem bloqueios
  • Esse fenômeno também é culpa da prática das equipes de segurança corporativa de bloquear ou interceptar tudo indiscriminadamente. Estou falando de vocês, equipes que usam Zscaler ou modo TLS middleman
  • Esse tipo de bloqueio também aparece em Wi‑Fi de aeroporto e em hotéis pelo mundo todo. Por exemplo, e-mail não funciona com o Apple Mail porque, por política corporativa, a porta 25 é bloqueada. Em nome de bloquear spam, eles também bloqueiam 143, 587, 993 etc., e no fim só deixam passar 80 e 443. Espero que o IPv6 melhore um pouco isso. E também queria que propostas como o ChatControl da UE parassem. Seria bom ouvir mais quem realmente entende de TI
  • Também entendo que a complexidade da inicialização da conexão de rede está aumentando, então faz sentido subir em cima de protocolos battle-tested e de melhores práticas. Mas ainda parece estranho continuar chamando de HTTP quando o tráfego real já não é mais hypertext
• É ótimo ver a funcionalidade do SSH evoluindo, mas se já vão praticamente reescrever tudo, eu gostaria que colocassem também recursos novos mais experimentais. Por exemplo, conveniências para lidar com “roaming/instabilidade temporária da rede”, como no Mosh https://mosh.org/
  • O grande diferencial do Mosh é a resposta extremamente rápida às teclas, quase como trabalhar direto em um shell local. Fico curioso se o SSH3 melhora isso de alguma forma. QUIC talvez ajude um pouco, mas ainda é diferente do Mosh
  • Pelo que entendo, suporte a connection migration e multipath já são características básicas do QUIC, e quanto à diferença entre roaming e um “tmux embutido”, não sei se o valor real está em isso ficar de fato integrado ao sistema
• Fico intrigado com a obsessão de algumas pessoas por nomes curtos/siglas; acho isso bem ruim. Hoje em dia, comandos podem ser longos, então prefiro nomes compridos e tecnicamente claros. O nome completo deveria ser o padrão, e abreviações poderiam ficar para alguns administradores de sistema ou distribuições, se quisessem encurtar. As pessoas deveriam aprender o nome por extenso. Por exemplo, Set-Location é preferível a cd; um nome como remote-terminals-over-http3 seria melhor que ssh3
• O último commit foi há um ano; alguém sabe como anda o projeto recentemente?
• Fiquei curioso sobre os planos do projeto. Já faz mais de um ano sem novidades, tanto em releases quanto em atividade no GitHub. Como parece algo que começou a partir de um artigo, imagino que talvez ainda estejam trabalhando em pesquisa relacionada ou em outras tarefas paralelas
  • Obrigado por apontar isso. Pessoalmente, considero este projeto encerrado. Com cerca de 239 commits, ele parece mais um proof of concept do que algo sério para uso real. Enquanto isso, o lado do OpenBSD (OpenSSH) continua extremamente ativo, então ainda não parece haver espaço real para substituí-lo https://github.com/openbsd/src/commits/master/
• A ideia do projeto é boa. Se der para fazer proxy por um proxy H3 comum, isso por si só já é promissor. E se ainda resolver multipath/migration e os problemas de bloqueio ligados a TCP, então já é um avanço enorme