☰

Não é possível concluir a conexão SSH após a troca bem-sucedida de chaves para o Ubuntu de algumas redes

tag-icon • tag-icon ssh
Não é possível concluir a conexão SSH após a troca bem-sucedida de chaves para o Ubuntu de algumas redes

Depois de voar de um país para outro, agora não consigo fazer ssh em vários dos meus servidores Ubuntu da Digital Ocean. No entanto, ainda consigo fazer login via console e ssh de uma caixa para outra (eles estão todos no mesmo data center físico).

Ao executar o ssh com -vvvv e executar o comando time com ele, a última mensagem de depuração é:

debug2: channel 0: open confirm rwindow 0 rmax 32768
Write failed: Broken pipe

O tempo limite expira após 1 minuto e 37 segundos.

Aqui está o log de depuração do ponto em que a autenticação da chave ssh foi bem-sucedida:

debug1: Authentication succeeded (publickey).
Authenticated to 128.199.170.168 ([128.199.170.168]:22).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug2: callback start
debug2: fd 3 setting TCP_NODELAY
debug3: packet_set_tos: set IP_TOS 0x10
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug1: Sending environment.
debug3: Ignored env TERM_PROGRAM
debug3: Ignored env SHELL
debug3: Ignored env TERM
debug3: Ignored env TMPDIR
debug3: Ignored env Apple_PubSub_Socket_Render
debug3: Ignored env TERM_PROGRAM_VERSION
debug3: Ignored env TERM_SESSION_ID
debug3: Ignored env USER
debug3: Ignored env SSH_AUTH_SOCK
debug3: Ignored env __CF_USER_TEXT_ENCODING
debug3: Ignored env PATH
debug3: Ignored env MARKPATH
debug3: Ignored env PWD
debug1: Sending env LANG = en_US.UTF-8
debug2: channel 0: request env confirm 0
debug3: Ignored env XPC_FLAGS
debug3: Ignored env PS1
debug3: Ignored env XPC_SERVICE_NAME
debug3: Ignored env SHLVL
debug3: Ignored env HOME
debug3: Ignored env GREP_OPTIONS
debug3: Ignored env LOGNAME
debug3: Ignored env SCALA_HOME
debug3: Ignored env SECURITYSESSIONID
debug3: Ignored env _
debug2: channel 0: request shell confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
Write failed: Broken pipe

A conexão não é particularmente lenta, meu shell é bash (e ainda consigo fazer login via console e outro ssh de rede). Nada parece estar bloqueando a conexão ssh, pois vejo a autenticação da chave pública ocorrendo.

Não sei em qual pipe está sendo gravado que está quebrado. FWIW Estou me conectando do OSX, mas não tive problemas até voar para os EUA.

Aqui está o que auth.logaparece ao tentar fazer login:

May 17 12:28:01 db1 CRON[24931]: pam_unix(cron:session): session opened for user root by (uid=0)
May 17 12:28:01 db1 CRON[24931]: pam_unix(cron:session): session closed for user root
May 17 12:28:02 db1 sshd[24955]: error: Could not load host key: /etc/ssh/ssh_host_ed25519_key
May 17 12:28:04 db1 sshd[24955]: Accepted publickey for tomo from 24.210.28.151 port 63202 ssh2: DSA 3a:[redacted]
May 17 12:28:04 db1 sshd[24955]: pam_unix(sshd:session): session opened for user tomo by (uid=0)

Captura TCPdump do tráfego da porta 22 durante uma tentativa de conexão:

    $ sudo tcpdump -i en0 port 22
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on en0, link-type EN10MB (Ethernet), capture size 65535 bytes
19:00:40.917870 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [S], seq 3430788632, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 1286503697 ecr 0,sackOK,eol], length 0
19:00:41.211348 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [S.], seq 4135716624, ack 3430788633, win 28960, options [mss 1460,sackOK,TS val 898678531 ecr 1286503697,nop,wscale 8], length 0
19:00:41.211415 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [.], ack 1, win 4117, options [nop,nop,TS val 1286503989 ecr 898678531], length 0
19:00:41.215051 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 1:22, ack 1, win 4117, options [nop,nop,TS val 1286503992 ecr 898678531], length 21
19:00:41.484824 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [.], ack 22, win 114, options [nop,nop,TS val 898678606 ecr 1286503992], length 0
19:00:41.488532 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [P.], seq 1:42, ack 22, win 114, options [nop,nop,TS val 898678609 ecr 1286503992], length 41
19:00:41.488616 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [.], ack 42, win 4116, options [nop,nop,TS val 1286504260 ecr 898678609], length 0
19:00:41.490182 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [.], seq 22:1470, ack 42, win 4116, options [nop,nop,TS val 1286504261 ecr 898678609], length 1448
19:00:41.490183 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 1470:1614, ack 42, win 4116, options [nop,nop,TS val 1286504261 ecr 898678609], length 144
19:00:41.491254 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [.], seq 42:1490, ack 22, win 114, options [nop,nop,TS val 898678609 ecr 1286503992], length 1448
19:00:41.592287 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [.], ack 1490, win 4096, options [nop,nop,TS val 1286504362 ecr 898678609], length 0
19:00:41.760341 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [P.], seq 1490:1674, ack 22, win 114, options [nop,nop,TS val 898678676 ecr 1286504260], length 184
19:00:41.760401 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [.], ack 1674, win 4090, options [nop,nop,TS val 1286504527 ecr 898678676], length 0
19:00:41.762375 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [.], ack 1614, win 136, options [nop,nop,TS val 898678676 ecr 1286504261], length 0
19:00:41.762409 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 1614:1638, ack 1674, win 4096, options [nop,nop,TS val 1286504529 ecr 898678676], length 24
19:00:42.027042 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [P.], seq 1674:1826, ack 1638, win 136, options [nop,nop,TS val 898678743 ecr 1286504529], length 152
19:00:42.027103 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [.], ack 1826, win 4091, options [nop,nop,TS val 1286504789 ecr 898678743], length 0
19:00:42.028104 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 1638:1782, ack 1826, win 4096, options [nop,nop,TS val 1286504790 ecr 898678743], length 144
19:00:42.300304 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [P.], seq 1826:2546, ack 1782, win 148, options [nop,nop,TS val 898678812 ecr 1286504790], length 720
19:00:42.300357 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [.], ack 2546, win 4073, options [nop,nop,TS val 1286505053 ecr 898678812], length 0
19:00:42.302441 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 1782:1798, ack 2546, win 4096, options [nop,nop,TS val 1286505055 ecr 898678812], length 16
19:00:42.600776 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [.], ack 1798, win 148, options [nop,nop,TS val 898678888 ecr 1286505055], length 0
19:00:42.600843 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 1798:1850, ack 2546, win 4096, options [nop,nop,TS val 1286505349 ecr 898678888], length 52
19:00:42.857852 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [.], ack 1850, win 148, options [nop,nop,TS val 898678952 ecr 1286505349], length 0
19:00:42.858552 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [P.], seq 2546:2598, ack 1850, win 148, options [nop,nop,TS val 898678952 ecr 1286505349], length 52
19:00:42.858584 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [.], ack 2598, win 4094, options [nop,nop,TS val 1286505604 ecr 898678952], length 0
19:00:42.859131 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 1850:1918, ack 2598, win 4096, options [nop,nop,TS val 1286505605 ecr 898678952], length 68
19:00:43.124310 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [P.], seq 2598:2650, ack 1918, win 148, options [nop,nop,TS val 898679019 ecr 1286505605], length 52
19:00:43.124374 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [.], ack 2650, win 4094, options [nop,nop,TS val 1286505867 ecr 898679019], length 0
19:00:43.124473 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 1918:2434, ack 2650, win 4096, options [nop,nop,TS val 1286505867 ecr 898679019], length 516
19:00:43.394690 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [P.], seq 2650:2702, ack 2434, win 159, options [nop,nop,TS val 898679086 ecr 1286505867], length 52
19:00:43.394774 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [.], ack 2702, win 4094, options [nop,nop,TS val 1286506134 ecr 898679086], length 0
19:01:04.685580 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 2434:2582, ack 2702, win 4096, options [nop,nop,TS val 1286527239 ecr 898679086], length 148
19:01:04.966270 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [P.], seq 2702:2738, ack 2582, win 170, options [nop,nop,TS val 898684479 ecr 1286527239], length 36
19:01:04.966378 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [.], ack 2738, win 4094, options [nop,nop,TS val 1286527514 ecr 898684479], length 0
19:01:04.967018 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 2582:2702, ack 2738, win 4096, options [nop,nop,TS val 1286527514 ecr 898684479], length 120
19:01:05.269214 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [.], ack 2702, win 170, options [nop,nop,TS val 898684555 ecr 1286527514], length 0
19:01:06.027067 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [P.], seq 2738:2790, ack 2702, win 170, options [nop,nop,TS val 898684744 ecr 1286527514], length 52
19:01:06.027144 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [.], ack 2790, win 4094, options [nop,nop,TS val 1286528563 ecr 898684744], length 0
19:01:06.027497 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 2702:3162, ack 2790, win 4096, options [nop,nop,TS val 1286528563 ecr 898684744], length 460
19:01:06.603432 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 2702:3162, ack 2790, win 4096, options [nop,nop,TS val 1286529135 ecr 898684744], length 460
19:01:07.552730 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 2702:3162, ack 2790, win 4096, options [nop,nop,TS val 1286530077 ecr 898684744], length 460
19:01:09.250116 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 2702:3162, ack 2790, win 4096, options [nop,nop,TS val 1286531762 ecr 898684744], length 460
19:01:12.442790 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 2702:3162, ack 2790, win 4096, options [nop,nop,TS val 1286534930 ecr 898684744], length 460
19:01:18.634929 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 2702:3162, ack 2790, win 4096, options [nop,nop,TS val 1286541067 ecr 898684744], length 460
19:01:24.068621 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 2702:3162, ack 2790, win 4096, options [nop,nop,TS val 1286546451 ecr 898684744], length 460
19:01:34.714519 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 2702:3162, ack 2790, win 4096, options [nop,nop,TS val 1286557019 ecr 898684744], length 460
19:01:45.384050 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 2702:3162, ack 2790, win 4096, options [nop,nop,TS val 1286567587 ecr 898684744], length 460
19:01:56.051835 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 2702:3162, ack 2790, win 4096, options [nop,nop,TS val 1286578155 ecr 898684744], length 460
19:02:06.715163 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 2702:3162, ack 2790, win 4096, options [nop,nop,TS val 1286588723 ecr 898684744], length 460
19:02:17.355823 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 2702:3162, ack 2790, win 4096, options [nop,nop,TS val 1286599291 ecr 898684744], length 460
19:02:28.042962 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 2702:3162, ack 2790, win 4096, options [nop,nop,TS val 1286609859 ecr 898684744], length 460
19:02:38.690971 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [R.], seq 3162, ack 2790, win 4096, length 0

Algumas outras coisas que tentei:

  • reduzindo o mtu no servidor, pode haver falha no pmtu: sudo ip link set mtu 1280 dev eth0
  • reduzindo mtu para 1280 no OS X para minha interface wifi
  • reduzindo ServerAliveInterval ainda mais, para 30, onde a conexão ainda expira, mas não com um cano quebrado
  • executando ssh com "cat" em vez de "bash" ou bash, mas sem perfil/rc carregado
  • configurando o endereço IP da interface wifi do OS X manualmente em vez de dhcp

Responder1

No rastreamento de pacotes, vemos que pacotes de tamanho máximo são trocados em ambas as direções no início do fluxo. Isso não causou nenhum problema, portanto não há nada que sugira um problema de MTU.

Mais tarde, durante a conexão, vemos que um pacote do cliente para o servidor com números de sequência relativos 2702:3162 nunca recebe um ACK do servidor.

Meu pensamento imediato é que essa perda de pacotes é causada por um middlebox defeituoso (ou seja, NAT, firewall ou similar).

Ouvi falar sobre caixas NAT que não conseguem lidar com alterações de TOS durante uma conexão TCP. O problema no seu caso acontece depois que o cliente indica que o TOS foi alterado. Porém, como o tcpdump não mostra o TOS, não posso dizer com certeza se esse é o ponto exato onde o problema acontece.

Para um teste, você pode tentar usar -o ProxyCommand='nc %h %p'de forma que o cliente ssh não controle diretamente a conexão TCP. Você também pode tentar a IPQoSopção. Se o problema for a alteração dos TOS, especificar -o IPQoS=cs0ou -o IPQoS=0deverá funcionar, mas qualquer outra configuração falhará. Isso ocorre porque o ssh está usando 0 como QoS durante a autenticação e depois muda para a QoS escolhida após a autenticação. Ao escolher QoS como 0, não haverá nenhuma alteração no valor de QoS para confundir middleboxes.

Responder2

Caso alguém se depare com isso, tive um problema semelhante com um roteador/modem TP-Link Archer VR2600 (com firmware 1.4.0 0.8.0 v0050.0 Build 160518 Rel.50944n).

Executar com -o IPQoS=0, conforme sugerido por @kasperd, funcionou, sugerindo algum tipo de problema de QoS com meu roteador. Ativei a coisa mais próxima que consegui encontrar nas configurações do roteador (Avançado→Controle de largura de bandadefinindo a largura de banda máxima logo abaixo do que está disponível na minha linha) sob a suposição de que o roteador pode começar a prestar atenção aos sinalizadores relevantes neste caso.

Isso pareceu funcionar e minhas conexões agora estão se concretizando. Alternar esta opção controla de forma confiável se consigo passar.

Responder3

Você tem uma configuração ssh de usuário (~/.ssh/config)?

Caso contrário, crie um e tente adicionar as seguintes linhas a ele:

ServerAliveInterval 120 #ping the server every 120s
TCPKeepAlive no #do not set SO_KEEPALIVE on socket

Responder4

Infelizmente, não tenho reputação suficiente aqui para votar ou comentar a resposta de Sam Mason acima, mas gostaria apenas de marcar publicamente com +1 o que ele disse. Também tenho um VR2600 e tive a mesma experiência:

  1. A conexão (ssh, sftp, etc) é feita, mas parece travar
  2. tshark mostra retransmissões espúrias de TCP
  3. configurar -o IPQoS=0 (por si só) do lado do cliente não fez nada
  4. possibilitandoa configuração Advanced->Bandwidth Control no roteador (anteriormente desativado), com os limites mais altos possíveis (= efetivamente ilimitado), parece consertar o roteador de forma que ele preste atenção ao sinalizador IPQoS
  5. tshark não mostra mais retransmissões falsas de TCP e a conexão não trava mais (clientes ssh, sftp, etc. agora funcionam com um servidor atrás do roteador VR2600).

Parece sugerir um bug significativo no roteador VR2600. Infelizmente (no momento em que escrevo), estou usando o firmware mais recente (1.4.0 0.8.0 v0050.0 Build 160518 Rel.50944n, igual ao Sam), e este roteador não parece ser compatível/testado com DD-WRT .

NO ENTANTO, para complementar o que foi discutido acima, direi também:

  1. Depois de executar as etapas 1 a 5, agora posso conectar-me com êxito, mesmo sem especificar "-o IPQoS = 0"

Em outras palavras:

Apenas ativar a opção Avançado->Controle de largura de banda nas opções do roteador (mesmo com um limite superior máximo) parece ser suficiente para fazer com que o NAT do roteador se comporte conforme o esperado. Se o controle de largura de banda estiver desabilitado, ocorre o problema descrito no OP (e detalhadamente por @malasa).

Não está claro se a solução é simplesmente ativar esta opção ou se você também precisa se conectar pelo menos uma vez com a opção -o. Em qualquer caso, posso confirmar que, depois de ter activado esta opção, se entãodesabilitaressa opção Avançado-> Controle de largura de banda, então meu ssh/sftp/etc está quebrado como antes. Se euhabilitarnessa opção Avançado-> Controle de largura de banda, tudo parece funcionar conforme o esperado novamente. E (tendo habilitado esta opção) tudo parece funcionar bem também nas reinicializações do roteador.

Portanto, é uma solução/correção muito boa que não requer alterações ou manutenção do lado do cliente, do meu ponto de vista (para responder à preocupação de @leonardoborges)

informação relacionada