Estou executando um script que emite comandos remotos por SSH para algumas caixas de produção. Existem chaves RSA no local para o usuário se conectar a essas caixas e, na maioria dos casos, não há problemas. Intermitentemente, recebo tempos limite de conexão, talvez uma vez em cada 20 conexões.
Estou usando o SSH2 como o protocolo, principalmente porque o SSH2 está disponível em todas as máquinas às quais estou me conectando. É assim que a saída de depuração se parece, até o ponto em que a conexão trava e depois fecha.
[mike@dev ~]$ ssh -v -o "Protocol=2" 10.60.###.### "w"
OpenSSH_4.3p2, OpenSSL 0.9.8b 04 May 2006
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 10.60.###.### [10.60.###.###] port 22.
debug1: Connection established.
debug1: identity file /home/mike/.ssh/id_rsa type 1
debug1: identity file /home/mike/.ssh/id_dsa type -1
debug1: loaded 2 keys
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.9p1
debug1: match: OpenSSH_3.9p1 pat OpenSSH_3.*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
Connection closed by 10.60.###.###
Conexão trava aqui e depois fecha.
Em algumas ocasiões, a conexão fica um pouco mais longe, mas é interrompida novamente.
...
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
Connection closed by 10.60.###.###
O log do servidor termina assim, nos casos em que a conexão morre:
Jul 23 16:53:07 host02 sshd[4989]: debug1: Client protocol version 2.0; client software version OpenSSH_4.3
Jul 23 16:53:07 host02 sshd[4989]: debug1: match: OpenSSH_4.3 pat OpenSSH*
Jul 23 16:53:07 host02 sshd[4989]: debug1: Enabling compatibility mode for protocol 2.0
Jul 23 16:53:07 host02 sshd[4989]: debug1: Local version string SSH-1.99-OpenSSH_3.9p1
Jul 23 16:53:07 host02 sshd[4990]: debug1: permanently_set_uid: 74/74
Jul 23 16:53:07 host02 sshd[4990]: debug1: list_hostkey_types: ssh-rsa,ssh-dss
Jul 23 16:53:07 host02 sshd[4990]: debug1: SSH2_MSG_KEXINIT sent
Jul 23 16:53:07 host02 sshd[4990]: debug1: SSH2_MSG_KEXINIT received
Jul 23 16:53:07 host02 sshd[4990]: debug1: kex: client->server aes128-cbc hmac-md5 none
Jul 23 16:53:07 host02 sshd[4990]: debug1: kex: server->client aes128-cbc hmac-md5 none
Jul 23 16:53:40 host02 sshd[4990]: debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
Jul 23 16:53:40 host02 sshd[4990]: debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
Jul 23 16:53:40 host02 sshd[4990]: debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
Jul 23 16:53:40 host02 sshd[4990]: Connection closed by ::ffff:192.168.1.203
Eu descobri que com um servidor eu tenho testado que, se eu usar o SSH1, não vi nenhuma conexão com falha. Mas eu estou querendo saber se isso pode ser corrigido para SSH2, ao invés de ter que abrir o SSH1 em todas as máquinas de produção.
Em 100 tentativas de conexão ...
Usando o SSH1: 100 conexões são bem-sucedidas. Usando o SSH2: aprox. 5 conexões falham.
Há algo (fácil) que estou perdendo?
Nós finalmente resolvemos isso algumas semanas atrás, e vale a pena acompanhar. Nós executamos uma VPN do nosso roteador de escritório local para o nosso firewall em nosso data center, ambos são da Cisco. Atualizamos o IOS no roteador e no firewall e isso parece ter funcionado.
Obrigado por todas as ideias / respostas que foram enviadas.
Poderia ser um problema de pesquisa do DNS? O IP do seu cliente está registrado no DNS? Talvez o tempo limite aconteça na primeira pesquisa e, em seguida, seja armazenado em cache por algum tempo.
Dê uma olhada nos pacotes TCP de uma conexão com falha. O 33s entre as duas entradas de log pode ser um resultado da conexão subjacente descartando pacotes ou falhando temporariamente. O gateway de VPN pode realmente "cair morto" enquanto tenta restabelecer o túnel. Os pacotes serão perdidos nessa situação sem que o ponto final do TCP perceba.
Basta executar tcpdump -i eth99 -s 0 -w ssh2-problem.pcap port 22 e ter uma conexão com falha. Em seguida, use Wireshark para examinar o arquivo de despejo. Um filtro de exibição de tcp.flags.syn == 1 and tcp.flags.ack == 0 fornece apenas o primeiro pacote de um fluxo TCP. Em seguida, use "Seguir fluxo TCP" no menu de contexto, ignore a caixa de diálogo e observe os pacotes de fluxo TCP com falha. Qualquer retransmissão excessiva (> > 1)?
Tags ssh connection