Questão SSH estranha, ssh funciona com -t mas congela sem ele

Question

Quando eu ssh em um dos meus servidores, parece fazer o login, mas depois trava antes de me dar o prompt ( message debug2: shell request accepted on channel 0 is the last log entry ).

Embora o estranho seja ssh -t "/bin/bash" funciona quando ssh não.

O que eu descobri até agora

• Eu posso fazer login de servidores na mesma localização geográfica normalmente
• Se eu ssh -t '/bin/bash' - posso fazer login perfeitamente em QUALQUER localidade.
• Se eu usar rsync para o servidor, parece funcionar e, em seguida, bloqueia
• Se eu usar rsync do servidor, ele funcionará sem problemas

O que eu tentei

• removendo ou alterando todas as opções de login .profile , .bashrc /etc/profile
• Alterando o ssh_config e / ou sshd_config para um de um servidor idêntico que funciona bem
• Eu verifiquei o roteamento
• Eu tive um especialista em rede examinando tcpdump sem sucesso (embora pareça haver muitas retransmissões)

Eu realmente não consigo pensar em mais nada

Além de um driver / firmware de placa de rede desonesto.

    

Answer 1

Isso pode vir de um problema no perfil.
Quando você se conectar com ssh -t /bin/bash , seu shell não fará o 'login', ele não irá originar o /etc/profile nem o ~/.profile e ~/.bashrc ...

Então, depois de conectar, coloque o shell no modo de depuração e, em seguida, digite cada arquivo para encontrar o que está bloqueando:

set -x 
. /etc/profile 
...and so on

EDITAR

Note que eu estava errado, o arquivo .bashrc será originado por qualquer shell interativo (portanto, apenas o perfil, os arquivos profile.d importam aqui).

Tente fazer a lista das diferentes fases do processo de conexão. Algo parecido com isto

1) ssh conectando (config, ...)
2) login (PAM, tty, wtmp, ...)
3) iniciando o shell (profile, home dir access, ...)

Para verificar o (1) você pode iniciar o daemon sshd no modo de depuração. Para isso, você precisa iniciar outro sshd, ouvindo uma porta dedicada (não na porta 22, portanto não é necessário parar o daemon sshd comum).

# /usr/sbin/sshd -p 2222 -ddd 

Esse sshd aceita apenas uma conexão e não entra em segundo plano. Abra outro terminal e conecte-se a essa sessão ssh.

# ssh -vvv -p 2222 user@host

Você pode comparar as mensagens que recebe com a de outro servidor da mesma marca. Então você saberá se o problema está no lado do ssh ou não.

(- ddd e -vvv são o nível máximo de depuração, você pode ajustar isso)

Recebi o link , muito mais detalhado, espero que ajude você.

    

Answer 2

A resposta para o meu problema Acontece que era um problema de rede. Eu finalmente descobri que, baixando um pouco o MTU de todas as placas de rede, o problema desapareceu.

O mais provável é que algo esteja mal configurado para essa rede, mas agora posso provar isso e entregá-lo à equipe da rede (que ficava me dizendo que era um problema no servidor).

Esteja ciente, porém, este é um último recurso A peculiaridade que eu tinha era que o servidor ssh funcionava da mesma sub-rede, mas não fora dela, e o ssh -t '/ bin / bash' funcionava de qualquer lugar.

Eu também tinha rsyncs que começariam bem, mas em algum momento apenas desligue ou desconecte a conexão.

Então, se você está olhando para esta resposta, tente os outros acima primeiro, e SOMENTE se você tiver esquisitices como o meu, é provável que isso ajude.

Então, obrigado por toda a ajuda. Eu tentei de tudo, e isso me ensinou muito, e deixe-me confirmar que não tinha nada a ver com o servidor (que é tudo que eu esperava).

Então, obrigado a todos que ajudaram

    

Answer 3

Quando você faz ssh some_user@some_host /bin/bash , o que você está fazendo é lançar o shell do some_user (como definido em /etc/passwd em algum_host ) e então executar o comando , /bin/bash , dentro desse shell.

Agora, o shell de some_user (vamos assumir que também é bash ) não está sendo lançado interativamente (está executando o comando especificado). Portanto, ele não aloca um pty (um pseudo-terminal ) e isso significa que não há um pty para o comando emitido usar para que ele inicie não interativamente.

No exemplo, o comando /bin/bash solicitado é ativado, mas parece travar.

Você pode consertar isso pedindo ao ssh para criar um arquivo de qualquer maneira, para que haja um disponível para o shell e seus processos filhos. Isso é o que o -t faz.

    $ ssh -t some_user@some_host bash

Você também pode consertar isso forçando o comando para criar um pty. Para bash , você faz isso passando um argumento -i . A seguinte linha de comando também deve funcionar:

$ ssh some_user@some_host bash -i

Observe, no entanto, que neste último caso, o shell não pode acessar /dev/tty e isso resulta em um aviso:

bash: no job control in this shell

As razões para isso são explicadas aqui . Isso pode ou não ser um problema, dependendo do que você planeja fazer no shell, mas usar ssh -t é provavelmente a melhor opção.

(note que você pode apenas passar bash como o comando porque ele deve estar no caminho do shell padrão do usuário)