Pregunta La conexión ssh tarda una eternidad en iniciarse, atascada en "prenda: 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í misma toma el mismo (ssh localhost). Una vez que la conexión finalmente se establece, es súper rápido interactuar con el servidor.

El uso de -vvv muestra que la conexión se atasca después de decir "prometer: red". En este punto, la autenticación (aquí usando la clave) ya está hecha, como se puede ver 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 pasó 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 contraseña en lugar de una clave
  • usando UsePrivilegeSeparation no en lugar de yes, en sshd_config

34
2017-07-28 14:02


origen


Por lo general, para mí las conexiones SSH lentas son problemas de DNS, ¿podría ser el caso aquí? Por ejemplo, el servidor puede quedarse atascado intentando hacer un DNS inverso para la IP del cliente y esperar a que se agote el tiempo de espera - Eric Renouf
En realidad no: de forma predeterminada, UseDNS no está definido en sshd_config y la página man dice que esta opción es "no" de forma predeterminada. - M-Jack
Algunas aplicaciones de Google sugieren que esto puede deberse a la actualización de systemd sin reiniciar. Y había una Actualización de systemd para xenial el 12 de julio.. systemctl restart systemd-logind soluciona el problema solo por un corto período de tiempo para mí. - Ivan Kozik
O si estas viendo pam_systemd(sshd:session): Failed to create session: Connection timed out como se menciona en una respuesta, esto podría ser github.com/systemd/systemd/issues/2925 - Ivan Kozik
Vine aquí después de una actualización, y la sugerencia de @ IvanKozik solucionó el problema, es decir, reiniciar systemd-logind del sistema, así que gracias por eso. - Paul M


Respuestas:


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

Puede comprobar si este es el problema abriendo el registro del demonio ssh (en Ubuntu debería ser /var/log/auth.log) y comprueba si tiene estas lineas:

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

Si es así, simplemente reinicie systemd-logind Servicio:

systemctl restart systemd-logind

Tuve este mismo problema en CentOS 7, porque el messagebus fue reiniciado (que es como el D-Bus El servicio se llama en CentOS).


37
2017-08-04 08:38



Intenté reiniciar systemd-logind pero, después de un tiempo, dice que el daemon PolicyKit se desconectó del bus. Ya no somos un agente de autenticación registrado. La tarea para systemd-logind.service falló porque se excedió un tiempo de espera. Consulte "systemctl status systemd-logind.service" y "journalctl -xe" para obtener más información. - Kun Ren
@KunRen probablemente necesites reiniciar el polkit servicio usando systemctl restart polkit. - Strahinja Kustudic
Esto funcionó para mí, gracias :) - Wolfe


Encontré la respuesta:

cambió UsePAM 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 sea la razón, incluso si aquí me estoy conectando con un usuario declarado en el propio servidor, no con uno LDAP.

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

Espero que esto pueda ayudar a alguien ...


12
2017-07-28 14:14



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 el usuario nagios no permitido porque la cuenta está bloqueada - M-Jack
Esto realmente no es una buena idea. - Jakuje
por qué ?? alguna alternativa? - M-Jack
El PAM se utiliza para otras cosas relacionadas con la administración de cuentas en sistemas modernos. En lugar de apagarlo, será mejor que investigue qué ocurre en la pila de PAM y por qué lleva tanto tiempo. - Jakuje
Dejando el módulo PAM muy sin uso habilitado Para SSH el acceso es un agujero de seguridad. Limitar el acceso a servicios críticos como SSH desde el punto de vista de 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 se utiliza passwd y shadow), cerrarla es perfectamente seguro. Todo usuario de PAM verá esto: cve.mitre.org/cgi-bin/cvekey.cgi?keyword=pam - Michal Sokolowski


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=no y UseDNS=no, o reiniciando systemd-logind, no hizo ninguna diferencia.)

En estos servidores, /etc/pam.d/postlogin contiene:

session     optional      pam_lastlog.so silent noupdate showfailed

La página del manual para pam_lastlog explica que el showfailed La opción será:

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

En estos servidores, el /var/log/btmp Los archivos eran enormes debido a muchos intentos fallidos de inicio de sesión. los btmp Los archivos de registro tampoco se estaban rotando.

Instalé el logrotate Paquete para asegurar que los archivos de registro se rotarán en el futuro. (En Fedora, la configuración enviada con logrotate Se maneja la rotación de sí mismo. /var/log/btmp.)

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


6
2018-06-10 23:23



¡Esto resolvió mi problema! Gracias. Buena atrapada. SSH estaba tomando 5-10 segundos, y ahora es menos que un abrir y cerrar de ojos. Esto es en una máquina virtual que he estado conectado a la Internet pública durante años. Sus reglas de cortafuegos 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- La mía era 2.7G de tamaño. - Carl Bennett


En mi caso el motivo fue un rsyslogd estrellado. Descubrí esto porque no había más mensajes de registro en, por ejemplo, / var / log / syslog o /var/log/mail.log

Asi que service rsyslog restart resolvió el problema por nosotros.


1
2018-06-29 07:44



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 corriendo, pero aparentemente no haciendo nada útil. - UtahJarhead


Para mí, este problema es causado por grandes (cientos de MB) btmp expediente. Este archivo registra los intentos de inicio de sesión. Cuando las personas están tratando de forzar su contraseña de forma bruta, este archivo puede ser grande y causar retrasos en la "pledge: network" fase.

Trate de borrar el archivo de registro

echo "" > /var/log/btmp

y ver si ayuda.


0
2018-06-15 10:38



Esto necesita mucha más explicación. Para empezar, ¿por qué crees que esto es útil? - Sven♦


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

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

Que era un archivo que era propiedad de root:root mientras estoy jenkins. Eliminar este archivo resolvió mis problemas.


0
2018-01-11 21:35