La conexión ssh tarda una eternidad en iniciarse, atascada en "promesa: red"

La conexión a uno de mis servidores mediante ssh tarda más de 20 segundos en iniciarse.

Esto no está relacionado con las condiciones de LAN o WAN, ya que la conexión a sí mismo toma lo mismo (ssh localhost). Después de que finalmente se establece la conexión, es súper rápido interactuar con el servidor.

El uso de -vvv muestra que la conexión está bloqueada después de decir "compromiso: red". En este punto, la autenticación (aquí usando la clave) ya está hecha, como se ve aquí:

...
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

(... atrapado aquí 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
...

El servidor es Ubuntu 16.04. Ya me sucedió en el pasado con otro servidor (era Ubuntu 12.04), nerver encontró la solución y el problema desapareció después de un tiempo ...

sshd_config es el predeterminado proporcionado por Ubuntu.

Hasta ahora he intentado:

• usando -o GSSAPIAuthentication = no en el comando ssh
• usando una contraseña en lugar de una clave
• usando UsePrivilegeSeparation no en lugar de yes, en sshd_config

Este es probablemente un problema con D-Busy systemd. Si el dbusservicio se reinicia por algún motivo, también deberá reiniciar systemd-logind.

Puede verificar si este es el problema abriendo el registro del demonio ssh (en Ubuntu debería serlo /var/log/auth.log) y verificar si tiene estas líneas:

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

En caso afirmativo, simplemente reinicie el systemd-logindservicio:

systemctl restart systemd-logind

Tuve este mismo problema en CentOS 7, porque messagebusse reinició (que es cómo D-Busse llama al servicio en CentOS).

encontré la respuesta:

UsePAM cambiado de sí a no en el archivo sshd_config

Después de reiniciar el servicio ssh, la conexión ahora es inmediata al servidor. En este servidor, PAM está vinculado a ldap, por lo que probablemente esa sea la razón, incluso si aquí me estoy conectando con un usuario declarado en el servidor, no uno LDAP.

Bueno, esta es más una forma de evitar el problema, no es realmente una solución ... Tengo otros servidores configurados de la misma manera que no tienen este problema.

Espero que esto pueda ayudar a alguien ...

Esto sucedió en dos de mis servidores Fedora 25, y se debió a muchos intentos fallidos de inicio de sesión SSH.

(Las sugerencias comunes de uso GSSAPIAuthentication=noy UseDNS=noreinicio systemd-logindno hicieron ninguna diferencia).

En estos servidores, /etc/pam.d/postlogincontiene:

session     optional      pam_lastlog.so silent noupdate showfailed

La página del manual pam_lastlogexplica que la showfailedopción:

Muestra el número de intentos fallidos de inicio de sesión y la fecha del último intento fallido de btmp.

En estos servidores, los /var/log/btmparchivos eran enormes debido a muchos intentos fallidos de inicio de sesión. Los btmparchivos de registro tampoco se rotaban.

Instalé el logrotatepaquete para asegurarme de que los archivos de registro se rotarán en el futuro. (En Fedora, la configuración que viene con logrotatemaneja la rotación de /var/log/btmp).

También eliminé los enormes btmparchivos de registro; Tan pronto como hice esto, la conexión a los servidores fue instantánea nuevamente.

En mi caso, la razón fue un rsyslogd bloqueado. Descubrí esto porque no había más mensajes de registro en, por ejemplo, / var / log / syslog o /var/log/mail.log

Entonces service rsyslog restartresolvió el problema para nosotros.

Para mí, este problema es causado por un btmparchivo grande (cientos de MB) . Este archivo registra los intentos de inicio de sesión. Cuando las personas intentan forzar su contraseña con fuerza bruta, este archivo puede ser grande y causar retrasos en la "pledge: network"fase.

Intenta borrar el archivo de registro

echo "" > /var/log/btmp

y ver si ayuda.

Para mí la solución fue agregar

UseDNS no

al /etc/ssh/sshd_configy luego, por supuesto service ssh restart(en nuestro servidor Debian / Jessie). Nada más...

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

despues :

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

Noté la siguiente línea en mis comentarios de depuración:

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

El cual era un archivo que pertenecía root:rootmientras yo estaba jenkins. Eliminar este archivo resolvió mis problemas.