ssh: canal xx: falha na abertura: falha na conexão: falha na abertura

0

Estou executando ssh em execução no macOS para redirecionar conexões para o soquete de domínio Unix local para um soquete de domínio em outra máquina. A linha de comando para a chamada ssh é aproximadamente a seguinte:

$ ssh -nNT -L /var/run/some.socket:/var/run/some.socket -o TCPKeepAlive=yes \
    -o ServerAliveCountMax=10 -o ServerAliveInterval=60 user@destination

Depois de realizar alguns testes de carga, descobri que, ocasionalmente, algumas conexões do cliente falham e, ao examinar os logs, descobri a seguinte saída de erro de ssh ao mesmo tempo que as conexões falham:

channel 41: open failed: connect failed: open failed
channel 44: open failed: connect failed: open failed
channel 47: open failed: connect failed: open failed
channel 49: open failed: connect failed: open failed
channel 51: open failed: connect failed: open failed
channel 59: open failed: connect failed: open failed
channel 62: open failed: connect failed: open failed
channel 64: open failed: connect failed: open failed

Os parâmetros do teste de carga devem executar 100 conexões simultâneas (conectar, enviar alguns dados, receber alguns dados, desconectar com um total de 10.000 conexões a serem executadas).

O comportamento observado é que, no início do teste, quando o primeiro conjunto de conexões é criado muito rapidamente, poucas conexões falham com os erros acima. Quantos intervalos falha de corrida para corrida, mas geralmente entre o casal e uma dúzia ou mais. A maioria das falhas tende a acontecer no início do teste, embora às vezes ocorra mais tarde no teste (ou seja, após as primeiras 100 terem sido feitas).

Outras postagens sobre SO com descrições similares parecem estar cobrindo o problema de usar localhost com solução alternativa para usar 127.0.0.1 , o que aqui não é relevante, pois não é um soquete TCP / IP. Além disso, a parte destination no comando acima é especificada como um endereço IP já.

Um pouco perdido sobre como corrigir e rastrear o problema. Eu tentei usar -vvv para obter um despejo detalhado da operação ssh com nada frutífero (tudo o que ele registra para os canais relevantes é que o soquete foi definido como não-bloqueador).

Observe que a chamada para ssh é feita a partir de um script e a chamada é precedida por ulimit -n 1024 , o que deve fornecer descritores de arquivos mais que suficientes para disponibilizar todos os soquetes.

    
por LB2 28.07.2018 / 01:07

1 resposta

1
channel 41: open failed: connect failed: open failed

Essa mensagem de erro significa que o servidor SSH remoto não pôde executar uma solicitação de encaminhamento TCP porque não pôde se conectar ao destino do túnel. A última parte "open failed" da mensagem é uma mensagem de erro do servidor SSH remoto.

Quando você executa o SSH com um encaminhamento de porta, o encaminhamento de porta funciona assim:

  1. O cliente ssh local ouve conexões TCP na porta local (/var/run/some.socket no seu caso).
  2. Quando um originador se conecta à porta local, o cliente ssh envia uma solicitação para um canal "direct-tcpip" para o servidor. A solicitação inclui o destino do túnel (/var/run/some.socket no sistema remoto no seu caso).
  3. O servidor SSH remoto faz uma conexão TCP ao destino do túnel.
  4. O cliente ssh local e o servidor ssh remoto transmitem dados em ambas as direções entre as respectivas conexões TCP e o canal direct-tcpip.

No seu caso, o servidor ssh está falhando na etapa 3 porque não pode se conectar ao destino do túnel por algum motivo.

Você deve verificar o log ssh no servidor remoto. O processo do servidor SSH pode ter registrado uma mensagem dizendo porque está falhando. Além disso, você diz que isso está acontecendo de forma intermitente durante um teste de carga, então eu observaria os problemas do lado do servidor relacionados ao carregamento. Algumas possibilidades vêm à mente:

  1. O aplicativo no sistema remoto que está escutando em /var/run/some.socket não está lidando com solicitações de conexão com rapidez suficiente, e um backlog está aumentando.
  2. O processo do servidor SSH está atingindo algum tipo de limite de recurso (número de descritores de arquivos abertos, por exemplo)
por 28.07.2018 / 15:04