SSH trava ao executar o comando remotamente

Question

• Cliente: OpenSSH_5.1p1 Debian-5ubuntu1 (Ubuntu 9.04)
• Servidor: OpenSSH_5.1p1 Debian-5 (Proxmox 2.6.24-7-pve)

Eu uso o SSH para executar comandos remotamente no servidor (módulo check_by_ssh do Nagios). Mas o SSH trava de vez em quando ao tentar executar comandos. Eu posso logar no servidor via SSH mas não executar um simples 'ls'. E parece bloquear de todos os clientes do mesmo endereço IP. A autenticação não é o problema, pode ser feita por chaves SSH ou senha.

ssh -l root -p 2222 server.domain.tld 'ls'

Aqui a informação de depuração do cliente

debug1: Entering interactive session.
debug2: callback start
debug2: client_session2_setup: id 0
debug1: Sending environment.
debug3: Ignored env ORBIT_SOCKETDIR
*** skipping approx 40 env var ignored
debug1: Sending command: ls
debug2: channel 0: request exec confirm 1

Ele paira lá. Então, depois de um tempo aleatório, ele funciona novamente (sem fazer nada). Matar todo o processo sshd no servidor parece funcionar também. Trabalha de um Putty. Eu vi que algumas pessoas tinham problemas como esse devido ao problema de DNS reverso do ISP, mas não parece ser o caso aqui.

Pode funcionar por horas e depois não trabalhar por meia hora ou mais.

O que poderia explicar esse comportamento?

EDITAR: Parece que com a opção -t ou -T, o ssh não trava, mas não consigo passar uma dessas opções no check_by_ssh dos nagios

    

Answer 1

Eu tive uma ideia para resolver meu problema neste blog. Eu também tenho um problema muito interessante

Eu tenho um link L2vpn (MPLS L2 fornecido pelo fornecedor) para conectar minha OH e a filial. Todos os testes de conectividade de ping estavam funcionando bem. Quando eu ssh usando o servidor debian de HO para um servidor debian no lado do cliente, eu posso logar naquele servidor, mas depois de fazer o login ssh remotamente no servidor de ramificação, não consegui executar os comandos ifconfig, htop ou ps -ef. Quando eu aplico esses comandos, a sessão congela. Evn que eu verifique no windows pc usando putty o resultado foi o mesmo. Coisa interessante é que quando eu uso o putty manager e ssh através desse aplicativo do win 7 pc ele estava funcionando bem. Depois de ler este blog eu tenho mpls mtu informações do provedor de serviços e tente o mesmo cenário com o tamanho mtu diferente na interface do servidor de origem debian no HO. Finalmente os tamanhos de mtu de 1440 a 1470 estavam funcionando bem onde, como padrões, o tamanho de mtu 1500 não estava funcionando. Conclusão: o tamanho mtu do servidor do debian tanto foi padrão, ou seja, 1500, mas no meio do caminho, onde os provedores de serviço MPLS L2vpn mtu tamanho foi falta de correspondência. obrigado

    

Answer 2

Eu tive o mesmo problema e hoje finalmente descobri o que estava causando o problema (pelo menos para mim). Isso pode ajudá-lo também.

Quando o ssh está configurando uma sessão, o campo de sinalizadores DSCP no cabeçalho IP é definido como 0x0. Se você estabelecer uma sessão interativa, ela será definida como 0x10 (16) e, se você estabelecer uma sessão não interativa, ela será definida como 0x8 (8). O cliente ssh define o campo DSCP com a chamada do sistema setsockopt () (que verifiquei na origem)

Uma configuração defeituosa em uma VPN no meu empregador estava descartando os pacotes com o DSCP de 0x8, fazendo com que todo o tráfego ssh não interativo também fosse descartado. Para verificar se era o campo DSCP que estava causando a queda, usei o iptables no servidor ssh para forçar o campo DSCP a ser configurado para 0x16 e testei meu tráfego não interativo (ssh ls, a mesma coisa que você estava tentando) e funcionou depois disso. Você também pode tentar a mesma coisa e ver se é por isso que sua sessão está suspensa.

Para definir DSCP para 0x10 em todo o tráfego ssh de saída do seu servidor ssh, execute:

$ sudo iptables -t mangle -A OUTPUT -p tcp --sport 22 -j DSCP --set-dscp 0x19

Esta foi em uma caixa de rhel 6.5.

    

Answer 3

Você pode estar atingindo um limitador de taxa SSH na rede do lado do servidor. Essa é uma técnica de firewall para bloquear endereços IP que possuem muitas novas solicitações de conexão em um curto período de tempo. Então o IP de origem é bloqueado por um período de tempo definido.

    

Answer 4

Verifique o ssh no lado do servidor. Você pode "strace" o processo criado / mail sshd e ver o que o syscalls está chamando. Isso deve lhe dar mais informações sobre o que está fazendo.

Tente também "touch / tmp / randomfile" e veja se o travamento acontece depois de criado ou depois.

    

Answer 5

Você verificou se há algum erro do PAM? só porque funciona a partir de massa não significa autenticação não é o problema.

    

Answer 6

Eu experimentei o mesmo ao ter problemas de MTU. Usando ciscos ipsec client-to-site e, em seguida, openvpn em cima disso. Basicamente, qualquer pacote com o tamanho de 1500 bytes congelaria a sessão.

    

Answer 7

Eu tive problema semelhante. O cliente e o MTU do servidor eram 9000. Depois que reduzi o MTU do cliente para 1500, o problema desapareceu.

    

Answer 8

Possivelmente, um problema de descoberta do MTU do caminho do ICMP .

Em nossa causa, todos os Parâmetros ICMP foram bloqueados pelo firewall no servidor lado. O decréscimo do MTU do lado do cliente (indicado por este texto ) resolveu o problema temporariamente. Mas depois de permitir todos (mas redirecionar) os parâmetros ICMP no lado do servidor, o problema desapareceu.

    

Answer 9

Um bloqueio no "comando de envio" pode ser causado pelo fato de o SSH realmente aguardar o código-chave / senha na chave. Pode-se descobrir se este é o caso apenas tirando o comando e SSH'ing no servidor sem um comando no final. Em seguida, pediria uma frase secreta.

    

Answer 10

Poderia haver algo no deadlocking ou atraso do ambiente de shell do usuário em aberto? A solução alternativa -t / -T e o fechamento de outras sessões ssh limpando isso soa como algo que está adquirindo um bloqueio com a suposição de que é o único processo.