ssh conexão demora sempre para iniciar, preso em "penhor: rede"

Question

A conexão com um dos meus servidores usando o ssh leva mais de 20 segundos para ser iniciada.

Isto não está relacionado a condições de LAN ou WAN, já que a conexão a si mesma leva o mesmo (ssh localhost). Depois que a conexão é finalmente estabelecida, é super rápido interratar com o servidor.

Usando -vvv mostra que a conexão está travada depois de dizer "penhor: rede". Neste momento, a autenticação (aqui usando a chave) já está feita, como é visível aqui:

...
debug1: Authentication succeeded (publickey).
Authenticated to myserver.mydomain.com ([xx.xx.xx.xx]:22).
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug1: pledge: network

(... preso aqui por 15 a 25 segundos ...)

debug1: client_input_global_request: rtype [email protected] want_reply 0
debug2: callback start
debug2: fd 3 setting TCP_NODELAY
debug2: client_session2_setup: id 0
...

O servidor é o Ubuntu 16.04. Já aconteceu comigo no passado com outro servidor (foi o Ubuntu 12.04), o nerver encontrou a solução e o problema desapareceu depois de um tempo ...

sshd_config é o padrão fornecido pelo Ubuntu.

Até agora eu tentei:

• usando -o GSSAPIAuthentication = no no comando ssh
• usando senha em vez de uma chave
• usando UsePrivilegeSeparation no em vez de sim, em sshd_config

Answer 1

Este é provavelmente um problema com D-Bus e systemd . Se o serviço dbus for reiniciado por algum motivo, você também precisará reiniciar o systemd-logind .

Você pode verificar se esse é o problema abrindo o registro do daemon do ssh (no Ubuntu ele deve ser /var/log/auth.log ) e verifique se ele possui estas linhas:

sshd[2721]: pam_systemd(sshd:session): Failed to create session: Connection timed out

Se sim, basta reiniciar systemd-logind service:

systemctl restart systemd-logind

Eu tive esse mesmo problema no CentOS 7, porque o messagebus foi reiniciado (que é como o serviço D-Bus é chamado no CentOS).

    

Answer 2

encontrou a resposta:

alterou o UsePAM de yes para no no arquivo sshd_config

Após reiniciar o serviço ssh, a conexão agora é imediata para o servidor. Neste servidor, o PAM está vinculado ao ldap, então essa é provavelmente a razão, mesmo se aqui eu estiver conectando com um usuário declarado no próprio servidor, não um LDAP.

Bem, isso é mais uma maneira de contornar o problema, não realmente uma solução ... Eu tenho outros servidores configurados da mesma maneira que não estão tendo esse problema.

Espero que isso ajude alguém ...

    

Answer 3

Isso aconteceu em dois dos meus servidores Fedora 25, e foi devido a várias tentativas de login com SSH com falha.

(As sugestões comuns de usar GSSAPIAuthentication=no e UseDNS=no ou reiniciar systemd-logind não fizeram diferença.)

Nestes servidores, /etc/pam.d/postlogin contém:

session     optional      pam_lastlog.so silent noupdate showfailed

A página man do pam_lastlog explica que a opção showfailed será:

Display number of failed login attempts and the date of the last failed attempt from btmp.

Nesses servidores, os arquivos /var/log/btmp foram enormes devido a várias tentativas de login com falha. Os arquivos de log btmp também não estavam sendo rotacionados.

Eu instalei o pacote logrotate para garantir que os arquivos de log serão rotacionados no futuro. (No Fedora, a configuração fornecida com logrotate manipula a rotação de /var/log/btmp .)

Eu também deletei os enormes arquivos de log btmp ; assim que fiz isso, a conexão com os servidores foi instantânea novamente.

    

Answer 4

No meu caso, o motivo foi um rsyslogd com falha. Descobri isso porque não havia mais mensagens de registro em, e. / var / log / syslog ou /var/log/mail.log

Então service rsyslog restart resolveu o problema para nós.

    

Answer 5

Para mim, esse problema é causado por um arquivo grande (centenas de MBs) btmp . Este arquivo registra as tentativas de login. Quando as pessoas estão tentando forçar sua senha, esse arquivo pode ser grande e causar atrasos na fase "pledge: network" .

Tente limpar o arquivo de log

echo "" > /var/log/btmp

e veja se isso ajuda.

    

Answer 6

Eu observei a seguinte linha no meu feedback de depuração:

Control socket connect(/var/lib/jenkins/.ssh/USER@HOST:22): Permission denied

Qual era um arquivo que pertenceu a root:root enquanto eu sou jenkins . A remoção desse arquivo resolveu meus problemas.

    

Answer 7

Para mim, a solução foi adicionar

UseDNS no

para o /etc/ssh/sshd_config e depois, é claro, service ssh restart (no nosso servidor Debian / Jessie). Nada mais ...

antes :

ssh git@git.*****.de true  0.03s user 0.01s system 0% cpu 13.440 total
ssh git@git.*****.de true  0.03s user 0.01s system 0% cpu 20.990 total
ssh git@git.*****.de true  0.03s user 0.02s system 0% cpu 31.114 total
ssh git@git.*****.de true  0.03s user 0.01s system 0% cpu 25.898 total

depois de :

ssh git@git.*****.de true  0.03s user 0.02s system 5% cpu 0.832 total
ssh git@git.*****.de true  0.03s user 0.01s system 7% cpu 0.523 total
ssh git@git.*****.de true  0.03s user 0.01s system 7% cpu 0.574 total