☰

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

tag-icon • tag-icon shell ssh login
Problema estranho de SSH, ssh funciona com -t mas congela sem ele

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

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

O que descobri até agora

  • Consigo fazer login normalmente em servidores na mesma localização geográfica
  • Se eu ssh -t '/bin/bash'puder fazer login perfeitamente em QUALQUER local.
  • Se eu usarrsync parao servidor, parece funcionar e depois bloqueia
  • Se eu usarrsync deo servidor, funciona sem problemas

O que eu tentei

  • removendo ou alterando todas as opções de login .profile,.bashrc /etc/profile
  • Alterando assh_config e/ou sshd_configpara um de um servidor idêntico que funciona bem
  • Eu verifiquei o roteamento
  • Fui examinado por um especialista em rede 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 duvidoso.

Responder1

Isso pode ser devido a um problema no perfil.
Quando você conecta com ssh -t /bin/bash seu shell não vai 'logar', não vai fonte o /etc/profilenem o ~/.profilee ~/.bashrc...

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

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

EDITAR

Observe que eu estava errado, o arquivo .bashrc será originado por qualquer shell interativo (portanto, apenas os arquivos profile e 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 inicial, ...)

Para verificar (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, então não há necessidade de parar o daemon sshd normal).

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

Esse sshd aceitará apenas uma conexão e não entrará 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 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 ajustar isso)

eu entendilink, muito mais detalhado.

Responder2

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

Provavelmente algo está configurado incorretamente para essa rede, mas agora posso provar isso e entregá-lo à equipe de rede (que sempre me dizia que era um problema no servidor).

Esteja ciente, porém, este é o último recurso A peculiaridade que tive foi que o servidor ssh funcionava na mesma sub-rede, mas não fora dela, e ssh -t '/bin/bash' funcionava em qualquer lugar.

Eu também tinha rsyncs que iniciavam bem, mas em algum momento simplesmente travavam ou desconectavam.

Portanto, se você está olhando para esta resposta, tente primeiro as outras acima, e SOMENTE se você tiver curiosidades como a minha, isso provavelmente ajudará.

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

Então obrigado a todos que ajudaram

Responder3

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

Funciona após reduzir o MTU de 1.500 para 1.400 no servidor de origem ou destino.

/sbin/ip link set dev eth0 mtu 1400

Responder4

Quando você faz isso ssh some_user@some_host /bin/bash, o que você está fazendo é lançaralgum_usuárioshell (conforme definido em /etc/passwdonalgum_host) e, em seguida, executar o comando fornecido, /bin/bash, de dentro desse shell.

Agora,algum_usuárioO shell de (vamos supor que também bash) não está sendo iniciado interativamente (em vez disso, ele está executando o comando fornecido). Portanto, não aloca um pty (umpseudo-terminal) e isso significa que não há um pty para o comando emitido usar, portanto ele inicia de forma não interativa.

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

Você pode corrigir isso solicitando ssha criação de um pty de qualquer maneira, para que haja um disponível para o shell e seus processos filhos. Isto é o que -tacontece.

    $ ssh -t some_user@some_host bash

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

$ ssh some_user@some_host bash -i

Observe, entretanto, 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 explicadasaqui. 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 simplesmente passar basho comando porque ele deve estar no caminho do shell padrão do usuário de qualquer maneira)

informação relacionada