francoismichel/ssh3Protocolo de shell rápido e seguro construído sobre HTTP/3, QUIC e TLS 1.3. Suporta OAuth2, OpenID Connect e autenticação SSH clássica com encaminhamento de porta UDP e capacidades de servidor oculto.
[!NOTE] SSH3 provavelmente vai mudar de nome. Ainda é o Protocolo de Conexão SSH (RFC4254) rodando sobre HTTP/3 Extended connect, mas as mudanças necessárias são pesadas e muito distantes da filosofia das implementações populares de SSH para serem consideradas para integração. O rascunho de especificação já foi renomeado ("Terminais Remotos sobre HTTP/3"), mas precisamos de algum tempo para criar um nome permanente adequado.
SSH3 é uma revisão completa do protocolo SSH, mapeando sua semântica sobre os mecanismos HTTP. Ele vem do nosso trabalho de pesquisa e nós (pesquisadores) o propusemos recentemente como um Internet-Draft (draft-michel-remote-terminal-http3-00).
Em poucas palavras, o SSH3 usa QUIC+TLS1.3 para estabelecimento de canal seguro e os mecanismos de Autorização HTTP para autenticação de usuário. Entre outros, o SSH3 permite as seguintes melhorias:
[!TIP] Quer começar rapidamente? Veja como instalar o SSH3. Você aprenderá a configurar um servidor SSH3 e usar o cliente SSH3.
Mais rápido para estabelecimento de sessão, não para vazão! O SSH3 oferece um estabelecimento de sessão significativamente mais rápido que o SSHv2. Estabelecer uma nova sessão com o SSHv2 pode levar de 5 a 7 viagens de ida e volta na rede, o que pode ser facilmente notado pelo usuário. O SSH3 precisa apenas de 3 viagens de ida e volta. A latência de digitação em uma sessão em execução permanece inalterada.
SSH3 (topo) VS SSHv2 (base) estabelecimento de sessão com um ping de 100ms para o servidor.
Enquanto o SSHv2 define seus próprios protocolos para autenticação de usuário e estabelecimento de canal seguro, o SSH3 depende dos mecanismos robustos e testados pelo tempo do TLS 1.3, QUIC e HTTP. Esses protocolos já são amplamente usados para proteger aplicações críticas de segurança na Internet, como comércio eletrônico e Internet banking.
O SSH3 já implementa os métodos comuns de autenticação baseada em senha e chave pública (RSA e EdDSA/ed25519). Ele também suporta novos métodos de autenticação como OAuth 2.0 e permite fazer login em seus servidores usando suas contas Google/Microsoft/Github.
Embora o SSH3 seja promissor para um estabelecimento de sessão mais rápido, ainda está em um estágio inicial de prova de conceito. Como qualquer novo protocolo complexo, uma revisão criptográfica especializada em um período prolongado é necessária antes que conclusões razoáveis de segurança possam ser feitas.
Estamos desenvolvendo o SSH3 como um projeto de código aberto para facilitar o feedback e a análise da comunidade. No entanto, ainda não podemos endossar sua adequação para sistemas de produção sem uma revisão por pares adicional. Colabore conosco se você tiver expertise relevante!
Dado o estado atual do protótipo, aconselhamos testar o SSH3 em ambientes isolados ou redes privadas. Esteja ciente que disponibilizar servidores experimentais diretamente acessíveis na Internet pode introduzir riscos antes de uma verificação de segurança aprofundada.
Embora ocultar servidores atrás de caminhos secretos tenha benefícios potenciais, isso não elimina a necessidade de uma análise rigorosa de vulnerabilidades antes de entrar em produção. Estamos animados com as possibilidades futuras do SSH3, mas incentivamos uma análise adicional primeiro.
Usando SSH3, você pode evitar o estresse usual de varredura e ataques de dicionário contra seu servidor SSH. Similarmente aos seus documentos secretos do Google Drive, seu servidor SSH3 pode ser ocultado atrás de um link secreto e responder apenas a tentativas de autenticação que fizerem uma requisição HTTP para este link específico, como o seguinte:
ssh3-server -bind 192.0.2.0:443 -url-path <my-long-secret>
Substituindo <my-long-secret> por, digamos, o valor aleatório M3MzkxYWMxMjYxMjc5YzJkODZiMTAyMjU, seu servidor SSH3 responderá apenas a tentativas de conexão SSH3 feitas à URL https://192.0.2.0:443/M3MzkxYWMxMjYxMjc5YzJkODZiMTAyMjU e responderá 404 Not Found para outras requisições. Atacantes e rastreadores na Internet não podem, portanto, detectar a presença do seu servidor SSH3. Eles verão apenas um simples servidor web respondendo códigos de status 404 para toda requisição.
NOTA BEM: colocar seu servidor SSH3 atrás de uma URL secreta pode reduzir o impacto de ataques de varredura, mas nunca substituirá os mecanismos de autenticação clássicos. O link secreto deve ser usado apenas para evitar que seu host seja descoberto. Saber a URL secreta não deve conceder acesso ao seu servidor. Use os mecanismos de autenticação clássicos descritos acima para proteger seu servidor.
SSH3 fornece novos recursos que não poderiam ser fornecidos pelo protocolo SSHv2.
Esta implementação SSH3 já fornece muitos dos recursos populares do OpenSSH, então se você está acostumado com o OpenSSH, o processo de adoção do SSH3 será tranquilo. Aqui está uma lista de alguns recursos do OpenSSH que o SSH3 também implementa:
~/.ssh/authorized_keys no servidorknown_hosts quando certificados X.509 não são usados.ssh-agent para autenticação por chave pública-proxy-jump). Se A é um cliente SSH3 e B e C são ambos servidores SSH3, você pode conectar de A a C usando B como gateway/proxy. O proxy usa encaminhamento UDP para encaminhar os pacotes QUIC de A para C, então B não pode descriptografar o tráfego SSH3 A<->C.~/.ssh/config no cliente e lida com as opções de configuração Hostname, User, Port e IdentityFile (as outras opções são atualmente ignoradas). Também analisa uma nova opção UDPProxyJump que se comporta de forma similar ao ProxyJump do OpenSSH.Ajude-nos a progredir o SSH3 de forma responsável! Acolhemos pesquisadores de segurança capacitados para revisar nossa base de código e fornecer feedback. Por favor, também nos conecte com órgãos normativos relevantes para potencialmente avançar o SSH3 através dos processos formais do IETF/IRTF ao longo do tempo.
Com assistência colaborativa, esperamos melhorar iterativamente o SSH3 em direção a uma prontidão segura para produção. Mas não podemos fazer afirmações de segurança definitivas de forma crível sem evidências de revisão criptográfica extensiva por especialistas e adoção por autoridades de segurança respeitadas. Vamos trabalhar juntos para realizar as possibilidades do SSH3!
Você pode baixar os binários da última versão,
instalá-lo usando go install ou gerar esses binários você mesmo compilando o código a partir da fonte.
[!TIP] O SSH3 ainda é experimental e é fruto de um trabalho de pesquisa. Se você tem receio de implantar publicamente um novo servidor SSH3, você pode usar o recurso de caminho secreto do SSH3 para ocultá-lo atrás de uma URL secreta.
go install github.com/francoismichel/ssh3/cmd/...@latest
Você precisa de uma versão recente do Golang para fazer isso. Baixar o código fonte e compilar os binários pode ser feito com os seguintes passos:
git clone https://github.com/francoismichel/ssh3 # clone o repositório
cd ssh3
go build -o ssh3 cmd/ssh3/main.go # compilar o cliente
CGO_ENABLED=1 go build -o ssh3-server cmd/ssh3-server/main.go # compilar o servidor, requer ter o gcc instalado
Se você tem privilégios de root/sudo e deseja tornar o ssh3 acessível a todos os usuários,
você pode copiar diretamente os binários para /usr/bin:
cp ssh3 /usr/bin/ && cp ssh3-server /usr/bin
Caso contrário, você pode simplesmente adicionar os executáveis à sua variável de ambiente PATH adicionando
a seguinte linha no final do seu .bashrc ou equivalente:
export PATH=$PATH:/caminho/para/o/diretorio/ssh3
Antes de conectar ao seu host, você precisa implantar um servidor SSH3 nele. Atualmente não
há um daemon SSH3, então por enquanto, você precisará executar o executável ssh3-server em segundo plano
usando screen ou um utilitário similar.
[!NOTE] Como o SSH3 roda sobre HTTP/3, um servidor precisa de um certificado X.509 e sua chave privada correspondente. Certificados públicos podem ser gerados automaticamente para seu nome de domínio público através do Let's Encrypt usando o argumento de linha de comando
-generate-public-certno servidor. Se você não quiser gerar um certificado assinado por uma autoridade certificadora real ou se não tiver um nome de domínio público, você pode gerar um autoassinado usando o argumento-generate-selfsigned-cert. Certificados autoassinados oferecem garantias de segurança similares ao mecanismo de chave de host do SSHv2, com o mesmo problema de segurança: você pode estar vulnerável a ataques de intermediário durante sua primeira conexão ao servidor. Usar certificados reais assinados por autoridades certificadoras públicas como Let's Encrypt evita esse problema.
Aqui está o uso do executável ssh3-server:
Uso do ./ssh3-server:
-bind string
o par endereço:porta para escutar, ex. 0.0.0.0:443 (padrão "[::]:443")
-cert string
o nome do arquivo do certificado do servidor (ou fullchain) (padrão "./cert.pem")
-key string
o nome do arquivo da chave privada do certificado (padrão "./priv.key")
-enable-password-login
se definido, habilita autenticação por senha (desabilitado por padrão)
-generate-public-cert value
Produzir e usar automaticamente um certificado público válido usando o Let's Encrypt para o nome de domínio fornecido. A flag pode ser usada várias vezes para gerar vários certificados. Se os certificados já foram gerados anteriormente usando esta flag, eles serão simplesmente reutilizados sem serem regenerados. Os certificados públicos são renovados automaticamente enquanto o servidor estiver em execução. Certificados públicos IP gerados automaticamente ainda não estão disponíveis.
-generate-selfsigned-cert
se definido, gera um certificado e chave autoassinados que serão armazenados nos caminhos indicados pelos argumentos -cert e -key (eles não devem existir previamente)
-url-path string
o caminho da URL secreta no qual o servidor ssh3 escuta (padrão "/ssh3-term")
-v modo verboso, se definido
-version
se definido, exibe a versão do software na saída padrão e sai
O comando a seguir inicia um servidor SSH3 público na porta 443 com um certificado público válido do Let's Encrypt
para o domínio my-domain.example.org e responde a requisições de nova sessão consultando o caminho da URL /ssh3:
ssh3-server -generate-public-cert my-domain.example.org -url-path /ssh3
Se você não tem um nome de domínio público (apenas um endereço IP), você pode usar um certificado existente
para seu endereço IP usando os argumentos -cert e -key ou gerar um certificado autoassinado usando o
argumento -generate-selfsigned-cert.
Se você tem certificados e chaves existentes, você pode executar o servidor da seguinte forma para usá-los:
ssh3-server -cert /caminho/para/certificado/ou/fullchain -key /caminho/para/chave/privada/do/certificado -url-path /ssh3
[!NOTE] Da mesma forma que o OpenSSH, o servidor deve ser executado com privilégios de root para fazer login como outros usuários.
Por padrão, o servidor SSH3 procurará identidades nos arquivos ~/.ssh/authorized_keys e ~/.ssh3/authorized_identities para cada usuário.
~/.ssh3/authorized_identities permite novas identidades como OpenID Connect (oidc) discutido abaixo.
Tipos de chave populares como rsa, ed25519 e chaves no formato OpenSSH podem ser usados.
Depois de ter um servidor SSH3 em execução, você pode conectar-se a ele usando o cliente SSH3 de forma similar ao que você fazia com sua ferramenta SSHv2 clássica.
Aqui está o uso do executável ssh3:
Uso do ssh3:
-pubkey-for-agent string
se definido, usa uma chave do agente cuja chave pública corresponde à do caminho especificado
-privkey string
arquivo de chave privada
-use-password
se definido, faz autenticação clássica por senha
-forward-agent
se definido, encaminha o agente ssh para ser usado com conexões sshv2 no host remoto
-forward-tcp string
se definido, aceita um localporta/remoteip@remoteporta encaminhando localhost@localporta para remoteip@remoteporta
-forward-udp string
se definido, aceita um localporta/remoteip@remoteporta encaminhando localhost@localporta para remoteip@remoteporta
-proxy-jump string
se definido, realiza um salto de proxy usando o host remoto especificado como proxy
-insecure
se definido, ignora a verificação do certificado do servidor
-keylog string
Escreve as chaves TLS QUIC e o segredo mestre no arquivo keylog especificado: apenas para fins de depuração
-use-oidc string
se definido, força o uso de OpenID Connect com a URL do emissor especificada como parâmetro
-oidc-config string
Arquivo de configuração JSON do OpenID Connect contendo os campos "client_id" e "client_secret" necessários para a maioria dos provedores de identidade
-do-pkce
se definido, realiza desafio-resposta PKCE com oidc
-v se definido, habilita modo verboso
Você pode conectar-se ao seu servidor SSH3 em my-server.example.org ouvindo em /my-secret-path usando a chave privada localizada em ~/.ssh/id_rsa com o seguinte comando:
ssh3 -privkey ~/.ssh/id_rsa [email protected]/my-secret-path
O cliente SSH3 funciona com o agente OpenSSH e usa a variável de ambiente clássica SSH_AUTH_SOCK para
se comunicar com este agente. Similarmente ao OpenSSH, o SSH3 listará as chaves fornecidas pelo agente SSH
e conectará usando a primeira chave listada pelo agente por padrão.
Se você quiser especificar uma chave específica para usar com o agente, você pode especificar a chave privada
diretamente com o argumento -privkey como acima, ou especificar a chave pública correspondente usando o
argumento -pubkey-for-agent. Isso permite autenticar em situações onde apenas o agente tem
acesso direto à chave privada, mas você tem apenas acesso à chave pública.
Embora desencorajado, você pode conectar-se ao seu servidor usando senhas (se explicitamente habilitado no ssh3-server)
com o seguinte comando:
ssh3 -use-password [email protected]/my-secret-path
ssh3 analisa sua configuração do OpenSSH. Atualmente, ele lida apenas com as opções Hostname; User, Port e IdentityFile do OpenSSH.
Também adiciona nova opção usada apenas pelo SSH3, como URLPath ou UDPProxyJump. URLPath permite que você omita o caminho da URL secreta em seu
comando SSH3. UDPProxyJump permite que você realize Salto de Proxy SSH3 e tem o mesmo significado que o argumento de linha de comando -proxy-jump.
Digamos que você tenha as seguintes linhas em sua configuração OpenSSH localizada em ~/.ssh/config :
IgnoreUnknown URLPath
Host my-server
HostName 192.0.2.0
User username
IdentityFile ~/.ssh/id_rsa
URLPath /my-secret-path
Similarmente ao que o OpenSSH faz, o seguinte comando ssh3 conectará você ao servidor SSH3 rodando em 192.0.2.0 na porta UDP 443 usando autenticação por chave pública com a chave privada localizada em .ssh/id_rsa :
ssh3 my-server/my-secret-path
Se você não quiser uma utilização baseada em configuração do SSH3, você pode ler as seções abaixo para ver como usar os parâmetros de CLI do ssh3.
Este recurso permite que você se conecte usando um provedor de identidade externo, como o da sua empresa ou qualquer outro provedor que implemente o padrão OpenID Connect, como Google Identity, Github ou Microsoft Entra. O fluxo de autenticação é ilustrado no GIF abaixo.
Conexão segura sem chave privada usando uma conta do Google.
A forma como ele se conecta ao seu provedor de identidade é configurada em um arquivo chamado ~/.ssh3/oidc_config.json.
Abaixo está um exemplo de arquivo config.json para uso com uma conta do Google. Este arquivo de configuração é um array
e pode conter várias configurações de provedores de identidade.
[
{
"issuer_url": "https://accounts.google.com",
"client_id": "<your_client_id>",
"client_secret": "<your_client_secret>"
}
]
Isso pode mudar no futuro, mas atualmente, para fazer este recurso funcionar com sua conta do Google, você precisará configurar um novo aplicativo experimental no console do Google Cloud e adicionar seu e-mail como usuários autorizados.
Isso fornecerá um client_id e um client_secret que você pode então definir em seu ~/.ssh3/oidc_config.json. No lado do servidor, você só precisa adicionar a seguinte linha em seu ~/.ssh3/authorized_identities:
oidc <client_id> https://accounts.google.com <email>
Atualmente consideramos remover a necessidade de definir o client_id no arquivo authorized_identities no futuro.
Frequentemente, alguns hosts SSH podem ser acessados apenas através de um gateway. O SSH3 permite que você realize um Salto de Proxy similarmente ao que é proposto pelo OpenSSH. Você pode conectar de A a C usando B como gateway/proxy. B e C devem estar ambos executando um servidor SSH3 válido. Isso funciona estabelecendo encaminhamento de porta UDP em B para encaminhar pacotes QUIC de A para C. A conexão de A para C é, portanto, totalmente ponta a ponta e B não pode descriptografar ou alterar o tráfego SSH3 entre A e C.