O SSH suporta chaves pré-compartilhadas *verdadeiras*?

Question

É de conhecimento geral que sshda execução em uma máquina publicamente disponível é um vetor de ataque delicioso e, portanto, deve ser protegida tanto quanto possível. Além de conselhos óbvios como "definir PermitRootLogincomo no" e "mudar para autenticação pubkey", descobri os seguintes métodos para restringir o acesso à minha máquina para script kiddies armados com nmap:

• Mude a porta para algo diferente de 22. Realmente não ajuda com o mencionado acima nmap.
• Deixe a porta 22 aberta, mas simplesmente descarte tudo o que chegar lá e aceite conexões SSH de outra porta usandoesta muleta. Melhor que o método anterior, mas ainda não passa de um obstáculo.
• Configure a batida na porta. Pesado eaindanão é perfeitamente seguro, porque o tráfego "batendo" pode ser interceptado.

Se eu fosse projetar um sistema para acesso remoto à minha máquina, ficaria assim:

1. Gere um segredo aleatório.
2. Copie-o manualmente para ambas as máquinas que devem estar conectadas (isso pode ser feito até mesmo usando um pen drive para máxima retenção anal).
3. Oprimeiro pacote(ou seja, o início do handshake SSH) que a máquina Cliente envia para o Servidor éjácriptografado com este segredo.
4. Se o Servidor receber um pacote não criptografado corretamente com este segredo, ele apenas fechará silenciosamente a conexão TCP.

O resultado é que éfisicamente impossívelpara um invasor descobrir que um serviço SSH está em execução no servidor. No meu headcanonesseé exatamente o que significa "chave pré-compartilhada".

Em vez disso, quando tento pesquisar "ssh com chave pré-compartilhada", não recebo nada além de links para artigos sobre como migrar de PasswordAuthenticationpara PubkeyAuthentication.

Answer 1

Não, isso não acontece. No nível do protocolo, toda conexão SSHv2 padrão sempre começa com 1) a versão do protocolo "banner" em ASCII simples, 2) um pacote não criptografado que lista todas as cifras suportadas e métodos de troca de chaves.

Começando com o passo 3 vocêpoderiaimplementar um método personalizado de troca de chaves que envolva um PSK (idealmentealém dissoà troca dinâmica usual de chaves DH), mas isso exigiria um daemon sshd personalizado, bem como clientes personalizados. Atualmente, esse recurso não existe no OpenSSH, nem no PuTTY, nem no Bitvise WinSSHD, nem em qualquer outra implementação SSHv2 com a qual eu brinquei até agora.

A alternativa mais simples seria usar um sistema VPN, já que eles frequentemente suportam PSKs (mas mais comumente como chaves HMAC para proteger a troca inicial de chaves - não como chaves AES para criptografar o canal de dados real, pois isso perderia o "sigilo direto " recurso). Depois de ter um serviço VPN em execução, você pode simplesmente desabilitar totalmente as conexões SSH diretas: ninguém pode descobrir um sshd que literalmente não está mais escutando.

Por exemplo, entre os mais populares, tanto o WireGuard quanto o OpenVPN suportam o uso de uma chave MAC pré-compartilhada para autenticar todas as tentativas de conexão. Como ambos usam UDP para negociação inicial, eles simplesmente não respondemde forma algumaa pacotes não verificáveis, tornando o serviço impossível de ser descoberto. (Embora eu acredite que o WireGuard já faz isso mesmo sem o modo PSK...) Observe que o OpenVPN chama esse recurso de modo "tls-auth" - não o confunda com seu modo "chave estática".

Também seria possível usar IPsec AH aqui – se tudo o que você precisa é de uma chave de autenticação completamente estática, seria possível configurar uma SA manualmente em ambas as extremidades sem precisar de nenhum handshake IKE dinâmico, apenas com um ip xfrmcomando. Mas pode ser irritante.

Como mais uma alternativa, alguns sistemas operacionais suportamNível TCPautenticação de chave pré-compartilhada usando TCP-MD5 (RFC1321) ou TCP-AO (RFC5925). Seria fácil invadir o software SSH, pois ele só precisa de um único sockopt, embora isso esteja novamente entrando no território de clientes personalizados. Além disso, o suporte no nível do sistema operacional é fraco – embora o TCP-MD5 ainda seja suportado, pois as pessoas desejam usá-lo com o BGP, o suporte para o TCP-AO pode ser praticamente inexistente.