A conexão SSH usando autenticação de chave pública / privada falha apenas para a porta 22

Estou lutando há horas para entender uma falha específica de conexão com um servidor SSH de um sistema macOS recente.

ssh [email protected] -p 22

Eu adicionei todas as chaves ~/.ssh/authorized_keysna máquina de destino. As chaves foram geradas com configurações padrão para ssh-keygen.

O servidor é uma instância do Ubuntu 18.04 provisionada recentemente no Azure, também tentamos um provedor de nuvem diferente.

Posso me conectar com sucesso com autenticação de chave pública / privada (PKA) de uma máquina Ubuntu. Não consigo me conectar à porta 22 com autenticação de chave pública / privada (PKA) da máquina macOS em questão.

o que estou perdendo?

Sintomas

Para conectar a partir da máquina macOS, observamos os seguintes sintomas:

• A conexão com o servidor funciona com autenticação de senha
• A conexão com o servidor não funciona com PKA
• Quando eu inicio um segundo servidor SSH usando /usr/sbin/sshd -d -p 2222, a conexão com o servidor funciona com PKA (usando ssh -p 2222no cliente)
• O mesmo para as portas 23, 80
• Mesmo comportamento usando
  • o cliente SSH integrado
  • um recém-preparado (versão 8.1p1 com brew install openssh)
  • cyberduck

Logs de clientes

Verifiquei os logs de ssh -vvvambas as portas. A única diferença (além das principais diferenças de host) são as seguintes linhas que estão faltando ao usar a porta 22 (isso torna muito difícil procurar o problema):

debug3: put_host_port: [machine]:2222\
...
debug3: put_host_port: [ip-address]:2222\
debug3: put_host_port: [machine]:2222\
...
debug3: receive packet: type 7\
debug1: SSH2_MSG_EXT_INFO received\
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>\

Parece que, ao se conectar à porta 22, o servidor não consegue enviar (ou o cliente não consegue receber) um "pacote do tipo 7" com SSH2_MSG_EXT_INFOe kex_input_ext_info.

Configuração do cliente

A saída de ssh -G(que mostra a configuração efetiva) é idêntica para a porta 22 e para outras portas.

Logs do servidor

Ao olhar para a saída de /usr/sbin/sshd -ddd, a seguinte entrada está faltando para a porta 22:

debug3: send packet: type 7 [preauth]

O servidor não envia um "pacote tipo 7"; mas talvez este seja apenas um sintoma não relacionado?

Também vejo as seguintes diferenças:

• Porta 22:

  debug2: KEX algorithms: curve25519-sha256,[email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1 [preauth]
  debug2: host key algorithms: [email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected],[email protected],ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa [preauth]
  

• Porta 80:

  debug2: KEX algorithms: curve25519-sha256,[email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,ext-info-c [preauth]
  debug2: host key algorithms: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa [preauth]
  

  Entradas extras (em comparação com a porta 22):

  • KEX algorithms: ext-c-info
  • host key algorithms: [email protected],[email protected]

  Ordem diferente:

  • ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,

Gambiarra

Para máquinas que estão sob meu controle, posso alterar a porta padrão do daemon SSH.

Questão

O que mais posso tentar reduzir o problema?

O problema aqui parece ser que você tem "algo" interferindo no tráfego de rede que está bloqueando especificamente sua tentativa de autenticação por meio de chaves na porta 22.

Esse "algo" pode ser denominado software de "proteção de endpoint" (firewall de software), pode ser um dispositivo de rede em sua rede (ou seja, roteador com inspeção profunda de pacotes, firewall, etc.) ou pode ser um dispositivo de rede na rede caminho ou na extremidade do servidor.

Esta parece ser a conclusão mais lógica, pois pode explicar por que não funciona na porta 22, mas funciona em outras portas.

Ou seja, se você não tivesse incluído as informações da porta, eu teria olhado para o arquivo authorized_keys no servidor. É possível especificar que uma chave específica só pode ser usada para autenticação ao se conectar a partir de um host específico - ou que não deve ser usada ao se conectar a partir de um host específico. Se você tivesse configurado isso para permitir o host Ubuntu e não o host Mac - isso poderia explicar partes do que você está vendo. No entanto, esse método não inclui a correspondência novamente com o número da porta - portanto, não pode explicar isso.

Isso tudo pressupõe que você está executando exatamente a mesma configuração para as portas 22 e 2222 (que você declarou que está) e que está executando o software OpenSSH padrão no servidor. Se não estiver, esse software pode incluir configuração para discriminar com base nas portas - mas não acho que seja provável.