Por que o ssh trava após “debug1: carregado com 3 chaves”?

3

Tentando efetuar login em uma instância do Amazon EC2 executando o Ubuntu 10.04.1. Eu posso logar muito bem, sem problemas. Um usuário diferente, vindo de uma rede diferente, consegue isso:

OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to xxxx [xxxx] port 80.
debug1: Connection established.
debug1: identity file /.ssh/identity type -1
debug1: identity file /.ssh/id_rsa type -1
debug1: identity file /.ssh/id_dsa type -1
debug1: loaded 3 keys

E então ele trava.

Nós tentamos rodar o sshd na porta 22 e na porta 80

Suponho que não seja um problema de firewall, pois a saída detalhada informa que a conexão está estabelecida.

Não vejo nada em /var/log/auth.log quando o usuário com falha se conecta. Eu vejo entradas quando entro com sucesso.

    
por James Moore 05.10.2010 / 02:52

3 respostas

3

Este é um sintoma que tenho visto em intervalos regulares, e aposto que isso é causado por um dos saltos entre o servidor em nuvem e a rede do usuário, filtrando mensagens ICMP indiscriminadamente, causando falha na descoberta da MTU do caminho; a troca de chaves é a primeira parte do protocolo SSH, na qual é provável que grandes segmentos TCP sejam enviados pelo soquete e, muito provavelmente, acione o problema.

Duas maneiras fáceis de isolar o problema: tente fazer grandes trocas sobre algum outro protocolo entre os mesmos hosts (por exemplo, fazer upload de algum arquivo em um formulário da web) ou forçar artificialmente o MTU no host do usuário para algum valor pequeno o suficiente para se adaptar a qualquer MTU plausível ao longo da rede (~ 300b). Se o problema aparecer durante outras grandes transferências e desaparecer com o menor MTU, você encontrou o culpado.

(O motivo é que quando um pacote IP que tem o conjunto de sinalizadores DF (não fragmentado) é transmitido e não passa por um salto, o salto responderá com uma mensagem ICMP e filtrará essas mensagens ICMP out é uma configuração incorreta comum por administradores de redes inexperientes ou excessivamente paranóicos - assim, o host remetente nunca sabe o caminho. O MTU é menor do que ele pensa e os pacotes simplesmente desaparecem no éter).

A má notícia é que isso não é algo que pode ser corrigido em qualquer ponto de extremidade em geral, mas no salto onde a filtragem imprópria está ocorrendo. Você pode contornar o problema com MTUs configuradas manualmente, mas isso é um hack feio e é quebradiço na melhor das hipóteses.

    
por 02.04.2012 / 17:30
0

Podemos eliminar o firewall de forma mais conclusiva, desligando a porta ssh na lista de controle de acesso ec2 e vendo como é a saída de depuração? Eu suspeito que você está certo, mas seria interessante ver a diferença.

Você tem algum outro controle de acesso acontecendo no lado da instância? Lista negra / whitelists do SSH?

    
por 05.10.2010 / 09:21
0

Eu sei que este é um segmento muito antigo, mas não respondeu satisfatoriamente (IMHO). Eu cheguei aqui pesquisando, outros também podem.

Eu resolvi esse problema verificando a configuração de rede. Meu cliente SSH tinha uma máscara de rede obsoleta, / 24 em vez de / 22. Atualizei a configuração, reiniciei a rede e foi bom.

    
por 02.03.2017 / 06:52

Tags