A conexão ssh leva uma eternidade para iniciar, presa à "promessa: rede"

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

Isso não está relacionado às condições da LAN ou WAN, uma vez que a conexão consigo mesma é a mesma (ssh localhost). Depois que a conexão é finalmente estabelecida, é super rápido interagir com o servidor.

O uso de -vvv mostra que a conexão está travada após dizer "penhor: rede". Neste ponto, a autenticação (aqui usando a chave) já está concluída, 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 no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network

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

debug1: client_input_global_request: rtype hostkeys-00@openssh.com 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 (era 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 yes, em sshd_config

Provavelmente, esse é um problema com D-Buse systemd. Se o dbusserviço for reiniciado por algum motivo, você também precisará reiniciar systemd-logind.

Você pode verificar se esse é o problema abrindo o log do daemon ssh (no Ubuntu deveria 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 o systemd-logindserviço:

systemctl restart systemd-logind

Eu tive esse mesmo problema no CentOS 7, porque o messagebusfoi reiniciado (que é como o D-Busserviço é chamado no CentOS).

encontrou a resposta:

mudou 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. Nesse servidor, o PAM está vinculado ao ldap, e esse é provavelmente o motivo, mesmo que aqui esteja me conectando com um usuário declarado no próprio servidor, e não no LDAP.

Bem, essa é 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 possa ajudar alguém ...

Isso aconteceu em dois dos meus servidores Fedora 25 e ocorreu devido a muitas tentativas falhas de login no SSH.

(As sugestões comuns de uso GSSAPIAuthentication=noe UseDNS=no/ ou reinicialização systemd-logindnão fizeram diferença.)

Nesses servidores, /etc/pam.d/postlogincontém:

session     optional      pam_lastlog.so silent noupdate showfailed

A página do manual pam_lastlogexplica que a showfailedopção irá:

Exibe o número de tentativas com falha de login e a data da última tentativa com falha de btmp.

Nesses servidores, os /var/log/btmparquivos eram enormes devido a muitas tentativas de login com falha. Os btmparquivos de log também não estavam sendo rotacionados.

Eu instalei o logrotatepacote para garantir que os arquivos de log sejam girados no futuro. (No Fedora, a configuração fornecida logrotatelida com a rotação de /var/log/btmp.)

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

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

Então service rsyslog restartresolvi o problema para nós.

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

Tente limpar o arquivo de log

echo "" > /var/log/btmp

e veja se isso ajuda.

Para mim, a solução foi adicionar

UseDNS no

para o /etc/ssh/sshd_confige, é 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

Percebi 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 pertencente a root:rootenquanto eu sou jenkins. A remoção deste arquivo resolveu meus problemas.