Não é possível completar a conexão SSH depois de trocar chaves para o Ubuntu de algumas redes

Question

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

Ao executar 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 é atingido após 1 minuto e 37 segundos.

Aqui está o log de depuração do ponto em que a autenticação da chave ssh é 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 eu ainda consigo acessar via console e outras redes ssh). Nada parece estar bloqueando a conexão ssh, já que vejo a autenticação da chave pública ocorrendo.

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

Aqui está o que auth.log mostra ao tentar fazer o 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)

Tcpdump captura 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 eu 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 baixo, 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 Wi-Fi do OS X manualmente em vez de dhcp

Answer 1

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

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

Meu pensamento imediato é que essa perda de pacotes é causada por uma middlebox defeituosa (por exemplo, NAT, firewall ou similar).

Eu ouvi falar sobre caixas NAT que não podem manipular a mudança de TOS durante uma conexão TCP. O problema no seu caso acontece depois que o cliente indica que o TOS foi alterado. No entanto, como o tcpdump não mostra os TOS, não posso dizer com certeza se esse é o ponto exato em que o problema acontece.

Para um teste, você pode tentar usar -o ProxyCommand='nc %h %p' de tal forma que o cliente ssh não controle diretamente a conexão TCP. Você também pode tentar a opção IPQoS . Se a alteração de TOS for o problema, a especificação de -o IPQoS=cs0 ou -o IPQoS=0 deve funcionar, mas qualquer outra configuração falharia. Isso ocorre porque o ssh está usando 0 como QoS durante a autenticação e, em seguida, alterna para a QoS escolhida após a autenticação. Ao escolher QoS como 0, não haverá qualquer alteração no valor da QoS para confundir as caixas do meio.

    

Answer 2

No caso de alguém mais se deparar com isso, eu 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 ).

A execução com -o IPQoS=0 , como sugerido por @kasperd, funcionou sugerindo algum tipo de problema de QoS com meu roteador. Eu habilitei a coisa mais próxima que encontrei nas configurações do roteador ( Avançado → Controle de Banda definindo largura de banda máxima logo abaixo do que está disponível na minha linha) supondo que o roteador pudesse iniciar prestar atenção às bandeiras relevantes neste caso.

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

    

Answer 3

Você tem um usuário ssh config (~ / .ssh / config)?

Se não criar 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

    

Answer 4

Eu também tenho um roteador tp-link (C9). Conexão direta do meu laptop para o meu (internet) servidor às vezes não estão funcionando ou pendurado, mas quando eu me conectar a outro servidor na mesma rede em que meu laptop está, não tenho problemas. O laptop está sempre conectado via wlan, meu servidor interno diretamente ao roteador.

infelizmente -o IPQoS = 0 e -o ProxyCommand = 'nc% h% p' não estava ajudando.

Então eu olhei para as configurações do meu roteador e desabilitei "NAT boost" e viola ele estava funcionando perfeitamente com conexões diretas. Para verificar foi realmente essa configuração eu habilitei novamente e: ainda trabalhando :-(

Eu suspeito que a reinicialização do roteador "corrigiu" o problema para mim. Até agora, ele está sendo executado por 3 dias e não teve problemas para conectar ou desconectar conexões como antes.

Agora tenho um script em execução testando a conexão o tempo todo e atualizarei minhas descobertas quando tiver os problemas novamente. Você pode querer testar se uma simples reinicialização do roteador também ajuda você.

    

Answer 5

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

1. A conexão (ssh, sftp, etc) é feita, mas parece ser interrompida
2. tshark mostra TCP Sprans Retransmits
3. definir -o IPQoS = 0 (por conta própria) do lado do cliente não fez nada
4. ativando a configuração Advanced & > Bandwidth Control no roteador (desativada anteriormente), com os limites mais altos possíveis (= efetivamente ilimitados), parece corrigir o roteador de forma a prestar atenção ao sinalizador IPQoS
5. tshark não mostra mais os TCP Spurious Retransmits e a conexão não trava mais (os clientes ssh, sftp, etc agora funcionam com um servidor atrás do roteador VR2600).

Parece sugerir um bug significativo no roteador VR2600. Infelizmente (como por escrito), eu estou no firmware mais recente (1.4.0 0.8.0 v0050.0 Build 160518 Rel.50944n, mesmo que Sam), e este roteador não parece ser compatível com / testado com DD-WRT .

No entanto, para adicionar ao que foi discutido acima, direi também:

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

Em outras palavras:

A simples ativação da opção Controle avançado de banda larga nas opções do roteador (mesmo com um limite máximo máximo) parece ser suficiente para que o NAT do roteador se comporte como esperado. Se o controle de largura de banda estiver desabilitado, o problema descrito no OP (e em detalhes por @malasa) ocorre.

Não está claro se a solução é simplesmente ativar essa opção ou se você precisa se conectar pelo menos uma vez com a opção -o também. De qualquer forma, posso confirmar que, depois de ter ativado esta opção, se eu desativar essa opção Advanced & > Bandwidth Control, então meu ssh / sftp / etc será quebrado como antes. Se eu ativar essa opção de controle de largura de banda avançada e > tudo parece funcionar como esperado novamente. E (tendo ativado esta opção) tudo parece funcionar bem através de reinicializações de roteador também.

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