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

44

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 [email protected]
debug1: Entering interactive session.
debug1: pledge: network

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

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
ssh Jack M
fuente
1
Por lo general, para mí las conexiones SSH lentas son problemas de DNS, ¿podría ser ese el caso aquí? Por ejemplo, el servidor puede estar atascado tratando de hacer un DNS inverso para la IP del cliente y esperando que se agote el tiempo de espera
Eric Renouf
En realidad no: por defecto, UseDNS no está definido en sshd_config y la página del manual dice que esta opción es "no" de forma predeterminada.
M-Jack
3
Algunos Google sugieren que esto puede ser causado al actualizar systemd sin reiniciar. Y hubo una actualización de systemd para xenial el 12 de julio . systemctl restart systemd-logindsoluciona el problema solo por un corto período de tiempo para mí.
Ivan Kozik
O si está viendo pam_systemd(sshd:session): Failed to create session: Connection timed outcomo se menciona en una respuesta, esto podría ser github.com/systemd/systemd/issues/2925
Ivan Kozik
Vine aquí después de haber tenido este problema después de una actualización, y la sugerencia de @ IvanKozik solucionó el problema, es decir, systemctl restart systemd-logind, así que gracias por eso.
Paul M

Respuestas:

43

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

Strahinja Kustudic
fuente
Traté de reiniciar systemd-logind pero después de un tiempo dice que el demonio PolicyKit se desconectó del bus. Ya no somos un agente de autenticación registrado. El trabajo para systemd-logind.service falló porque se excedió el tiempo de espera. Consulte "estado de systemctl systemd-logind.service" y "journalctl -xe" para más detalles.
Kun Ren
@KunRen probablemente necesite reiniciar el polkitservicio usando systemctl restart polkit.
Strahinja Kustudic
16

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

Jack M
fuente
1
cambiar UsePAM a no tiene otros efectos. Ver esta discusión Así que tuve que establecer una contraseña para el usuario, porque recibí errores como User nagios no permitido porque la cuenta está bloqueada
M-Jack
44
Esto realmente no es una buena idea.
Jakuje
1
por qué ?? alguna alternativa?
M-Jack
8
El PAM se usa para otras cosas relacionadas con la administración de cuentas en los sistemas modernos. En lugar de apagarlo, será mejor que investigue lo que está sucediendo en la pila PAM y por qué lleva tanto tiempo.
Jakuje
Dejar un módulo PAM que no se usa con mucha frecuencia habilitado para el acceso SSH es un agujero de seguridad. Limitar el acceso a servicios críticos como SSH desde el punto de vista de la seguridad siempre es una buena idea para CUALQUIER otro servicio también. ¿Cuándo quieres que el módulo PAM coopere con SSH? Por ejemplo: cuando necesita integrarlo con el directorio activo a través de winbind, cuando necesita autenticación de dos factores con tokens de Google, etc. En otros casos (cuando usa passwd y shadow), apagarlo es perfectamente seguro. Todos los usuarios de PAM verán esto: cve.mitre.org/cgi-bin/cvekey.cgi?keyword=pam
Michal Sokolowski
10

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.

Richard Fearn
fuente
¡Esto resolvió mi problema! Gracias. Buena atrapada. SSH tardaba entre 5 y 10 segundos, y ahora es menos que un abrir y cerrar de ojos. Esto está en una máquina virtual que he estado conectado a Internet público durante años. Sus reglas de firewall probablemente podrían ajustarse un poco mejor, ahora que lo pienso. Para otros, esto es todo lo que hice: sudo truncate -s 0 /var/log/btmp- El mío tenía un tamaño de 2.7G.
Carl Bennett
2

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.

control aleatorio
fuente
La misma causa en un servidor nuestro que ejecuta CentOS 6.10. El reinicio de rsyslog se encargó de ello. La cosa es que no estaba muerto. Estaba funcionando, pero aparentemente no hacía nada útil.
UtahJarhead
1

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.

Marek Nagy
fuente
3
Esto necesita mucha más explicación. Para empezar, ¿por qué crees que esto es útil?
Sven
consejo: solo escribir :> /var/log/btmphace lo mismo por cierto.
Marius
1

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
tamasgal
fuente
No, agregar UseDNS noes una solución para un problema completamente diferente.
Kasperd
@kasperd No importa. En mi caso, tuve los mismos síntomas (brevemente: atascado después de decir "compromiso: red") y esto es lo que finalmente ayudó, así que esta es una solución al menos a un problema muy similar y estoy seguro de que ayudará a uno o al otro en algún momento.
tamasgal
Lo mismo aquí, dos bloqueos durante la conexión, uno después sign_and_send_pubkey, uno más largo después pledge: network. Agregar solo UseDNS nocon posterior service ssh restartresolvió el problema en una instalación anterior de Ubuntu 14.04.5 LTS aquí.
Sabueso
0

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.

Ambidex
fuente