Problema SSH estranho, o ssh funciona com -t mas congela sem ele

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

Embora o estranho é que ssh -t "/bin/bash"funciona quando sshnão funciona .

O que eu descobri até agora

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

O que eu tentei

• remover ou alterar todas as opções de login .profile,.bashrc /etc/profile
• Alterar o ssh_config e / ou sshd_config para um de um servidor idêntico que funciona bem
• Eu verifiquei o roteamento
• Um especialista em rede examinou tcpdumpsem 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.

Isso pode resultar de um problema no perfil.
Quando você se conectar com ssh -t /bin/bash seu shell não vai 'login', não será fonte do /etc/profilenem o ~/.profilee ~/.bashrc...

Então, após a conexão, coloque o shell no modo de depuração e, em seguida, procure cada arquivo para encontrar o que está bloqueando:

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

EDITAR

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

Tente fazer a lista das diferentes fases do processo de conexão. Algo assim

1) conexão ssh (config, ...)
2) login (PAM, tty, wtmp, ...)
3) iniciando o shell (perfil, acesso ao diretório home, ...)

Para verificar o (1), você pode iniciar o daemon sshd no modo de depuração. Para isso, é necessário 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 recebidas com as de outro servidor da mesma marca. Então você saberá se o problema está no lado ssh ou não.

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

Eu tenho esse link , muito mais detalhado.

A resposta para o meu problema Parece que foi um problema de rede. Acabei descobrindo que, diminuindo um pouco o MTU de todas as placas de rede, o problema desapareceu.

Provavelmente algo está 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 de que este é o último recurso. A peculiaridade que tive era que o servidor ssh trabalhava na 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 simplesmente desligue ou desligue a conexão.

Portanto, se você estiver olhando para essa resposta, tente primeiro as outras acima, e SOMENTE se você tiver esquisitices como a minha, é 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 o que eu esperava).

Então, obrigado a todos que ajudaram

Quando o fizer ssh some_user@some_host /bin/bash, o que você está fazendo está lançando algum_usuário 's shell (como definido no /etc/passwdno some_host ) e, em seguida, executar o comando dado, /bin/bash, de dentro do shell.

Agora, o shell de some_user (suponha que também bashseja) não está sendo iniciado interativamente (está executando o comando fornecido). Portanto, ele não aloca um pty (um pseudo-terminal ) e isso significa que não há um pty para o comando emitido usar, portanto ele é iniciado de maneira não interativa.

No exemplo, o /bin/bashcomando solicitado é iniciado, mas parece travar.

Você pode corrigir isso pedindo sshpara criar um pty de qualquer maneira, para que haja um disponível para o shell e seus processos filhos. Isto é o que -tfaz.

    $ ssh -t some_user@some_host bash

Você também pode corrigir isso forçando o comando a criar um pty. Pois bashvocê faz isso passando um -iargumento. 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/ttye 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.

(observe que você pode apenas passar bashcomo o comando, porque ele deve estar no caminho do shell padrão do usuário)

Eu tenho o mesmo problema quando usei uma plataforma de virtualização aninhada recentemente.

Funciona após reduzir o MTU de 1500 para 1400 no servidor de origem ou destino.

/sbin/ip link set dev eth0 mtu 1400