SSH lento al iniciar sesión

8

Iniciar un shell interactivo sobre SSH es lento para uno de mis servidores. Todo lo que lleva a eso, incluido el cifrado de negociación, es rápido, pero luego se cuelga durante 45 segundos. Después de eso, termina y tengo una concha. ¿Cómo identifico lo que está colgando? Traté de limpiar el entorno e inhabilitar todo el reenvío en caso de que eso fuera más lento pero no sirvió de nada. Aquí está mi comando de prueba:

env -i ssh -x -a -vvv server

y aquí está la salida de SSH:

debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
*(hangs for 45 seconds here)*
debug3: Wrote 128 bytes for a total of 3191
debug2: callback start
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug1: Sending environment.

— pingüino359
fuente

unix.stackexchange.com/questions/10476/…

— forcefsck

@forcefsck No creo que esa publicación sea relevante. Mi conexión inicial es rápida, las claves se intercambian, la autenticación es rápida, sin esperar una solicitud de contraseña como en la publicación anterior. Además, todo el DNS directo e inverso debería estar terminado en este punto, estoy bastante seguro. Además, este problema no es intermitente como en la publicación anterior, es cada vez. La salida detallada que publiqué anteriormente comienza justo después del mensaje de autenticación exitosa. Creo que es más similar a bash o que un módulo de sesión de pam tarda en iniciarse.

— penguin359

¿Hay algún retraso para las sesiones no interactivas también? ¿Hay algún retraso cuando inicia una segunda conexión mientras una está activa? ¿Qué método de autenticación usas? ¿Su directorio de inicio está montado automáticamente al iniciar sesión de alguna manera (remota o encriptada)? Un módulo de pam podría ser la culpa, ¿qué tiene /etc/pam.d/sshd(o como se llame en su sistema)? Si tiene acceso a los registros del servidor, ¿hay algo relevante?

— Gilles 'SO- deja de ser malvado'

@Gilles Sí, parece afectar los comandos remotos, scp y sftp. Si quiere decir dos conexiones SSH separadas, ambas son lentas. Si te refieres a comenzar una segunda sesión a través del mismo zócalo de control, acabo de intentarlo y es rápido, pero recibo una advertencia sobre la falla de xauth para bloquear .Xauthority. Utilizo cualquier cosa, desde teclado interactivo, publickey, basado en host, hasta gssapi-keyex. La autenticación siempre es rápida independientemente, aunque la velocidad varía ligeramente. Mi directorio personal es local para el servidor y no está encriptado. PAM es esencialmente Ubuntu predeterminado + pam_krb5.so instalado.

— penguin359

Dices "lento a uno de mis servidores". ¿Se comporta normalmente cuando sshing a otras máquinas? ¿Y esto es desde su máquina doméstica, en la que ha iniciado sesión localmente? ¿Cuál es el sistema operativo en local y remoto (incluida la versión)? Además, ¿es normal sshing desde el servidor a su máquina doméstica? ¿Sshing como otro usuario (tanto local como remoto) hace alguna diferencia?

— Faheem Mitha

6

En un caso muy similar, fue uno de los scripts update-motd.

Lo siguiente hizo el truco:

sudo rm /etc/update-motd.d/90-updates-available

Aquí hay un pequeño ayudante que mide el tiempo de cada script:

$ for f in /etc/update-motd.d/*;do echo $f;time $f;done
/etc/update-motd.d/00-header            0m0.007s
/etc/update-motd.d/10-help-text         0m0.005s
/etc/update-motd.d/90-updates-available 0m49.163s
/etc/update-motd.d/91-release-upgrade   0m0.152s
/etc/update-motd.d/98-fsck-at-reboot    0m0.015s
/etc/update-motd.d/98-reboot-required   0m0.003s
(output reduced to the relevant parts)

— Daniel Alder
fuente

¡Gracias! La mayoría de las personas solo recomiendan desactivar el DNS, pero mi inicio de sesión ssh todavía era lento. Comencé a investigar el proceso de inicio de sesión, y su respuesta me señaló a /etc/update-motd.d/50-landscape-sysinfo, que parecía ser lento.

— Rennex

1

Esto es realmente útil, para mí el asesino fue 50-landscape-sysinfo. Y para su información, simplemente puede chmod -x /etc/update-motd.d/90-updates-availableevitar que se ejecute al iniciar sesión en lugar de eliminarlo por completo.

— billynoah

3

pam_krb5.so se configuró para adquirir tokens AFS para un shell inexistente que tenía un tiempo de espera de 30 segundos para detener cualquier autenticación usando ese módulo, no solo SSH. Eliminado eso y la autenticación ocurre mucho más rápido.

— pingüino359
fuente

2

Si su servidor ssh tiene activado el mapeo DNS inverso, podría ser la causa del retraso, busque VerifyReverseMappingen el /etc/ssh/sshd_configarchivo del servidor.

— Frederik Deweerdt
fuente

1

Pensé que el mapeo DNS inverso ocurrió antes de que se permitiera que la autenticación tuviera éxito, pero lo probaré.

— penguin359

Creo que te refieres a UseDNS, recibí una advertencia depreciada en VerifyReverseMapping. De todos modos, puse ambos en no y no ayudó. Me aseguro de asegurarme de que mi asignación inversa sea correcta y que el host pueda asignar el nombre de host de mi cliente a un registro A y viceversa sin ningún problema.

— penguin359

0

Tuve el mismo problema, pero aparentemente causado por algo más. La solución:

/etc/ssh/sshd_config:
#UsePAM yes

y:

sudo /etc/init.d/ssh stop;sudo /etc/init.d/ssh start;

— Ole Tange
fuente