Largo tiempo de espera al iniciar sesión

Cuando inicio sesión en mi servidor obtengo esto:

No mail.
Last login: Fri Nov  5 14:22:45 2010...

entonces debo esperar 5 segundos y luego está listo ...

wolfy@ubuntu-server:~$

¿Es normal este tiempo de espera o debo hacer algo para "repararlo"?

Esto suele ser el resultado de la pam_motdregeneración del /etc/motdarchivo. Puede verificar las secuencias de comandos individuales /etc/update-motd.dpara ver si algo es especialmente lento.

Tengo los mismos problemas con 10.04 (LTS).

Cuando ejecuto mi ssh con -vvv, muere a las:

debug1: Entering interactive session.

Extendiendo esta respuesta.

Logré reiniciar el servidor de forma remota y habilité el registro de DEPURACIÓN. También aproveché esta oportunidad para permanecer conectado y observar otros intentos de inicio de sesión. Aquí está lo que pasa. El cliente se conecta y está autorizado y se cuelga en el mensaje anterior.

En el servidor, la lista de procesos muestra esto:

root       835  0.0  0.1  11476  3348 ?        Ss   13:39   0:00 sshd: till [priv]
root       840  0.0  0.0   4804  1124 ?        S    13:39   0:00 /bin/sh -c /usr/bin/env -i PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin /bin/run-parts --lsbsysinit /etc/update-motd.d
root       841  0.0  0.0   4728  1108 ?        S    13:39   0:00 /bin/run-parts --lsbsysinit /etc/update-motd.d
root       854  0.0  0.0   4804  1144 ?        S    13:39   0:00 /bin/sh /etc/update-motd.d/50-landscape-sysinfo
root       861  0.2  0.5  15388  9248 ?        S    13:39   0:00 /usr/bin/python /usr/bin/landscape-sysinfo
root       863  0.0  0.0      0     0 ?        Z    13:39   0:00 [who] <defunct>

Puedo ejecutar /usr/bin/python /usr/bin/landscape-sysinfobien mientras estoy conectado, pero por alguna razón, no puedo entender por qué detiene el proceso de inicio de sesión. Cuando finalizo el proceso, el inicio de sesión continúa con la solicitud y es exitoso .

Esto no parece ser un problema ssh (d), sino que está más relacionado con el update-motdpaisaje. Desinstalé el update-motdpaquete, pero parece que el /etc/update-motddirectorio persiste y los scripts todavía se ejecutan, lo que hace que el proceso se bloquee.

Depurando esto aún más:

Resulta que el /etc/update-motd.d/directorio realmente no pertenece al paquete update-motd, parece ser activado por la autenticación de pam a través de sshd.

¡Parece que lo he clavado!

Deshabilitado pam_motd en los siguientes archivos:

• /etc/pam.d/sshd
• /etc/pam.d/login

Uno mas:

apt-get purge landscape-client landscape-common

Estos parecen ayudar en cierta medida. Sin embargo, solo elimina el script ofensivo /etc/update-motd.d/y no elimina todos los scripts en ese directorio ni tampoco se elimina pam_motd.

En general, no encontré ninguna manera de deshabilitarlo pam_motdcompletamente porque parece, lo que sea que haga, ralentiza el proceso de inicio de sesión hasta cierto punto. No se bloquea como el script landscape-common, pero es más lento.

Informe de error sobre este tema:

• https://bugs.launchpad.net/ubuntu/+source/pam/+bug/805423

Soluciones a partir de ahí:

Tienes razón en que la capacidad de iniciar sesión es más importante que presentar un motd. Si este comportamiento es un problema para usted, hay varias formas en que puede deshabilitarlo:

• comente la línea 'pam_motd' /etc/pam.d/sshdsi no desea mostrar un motd.
• Eliminar el contenido del /etc/update-motd.ddirectorio.
• chmod -x los scripts /etc/update-motd.dque no quieres ejecutar.

Finalmente encontré la solución:

1. sudo apt-get remove landscape-client landscape-common
2. línea de comentario session optional pam_motd.so en /etc/pam.d/loginy/etc/pam.d/sshd

¡Ahora iniciar sesión es INSTANTÁNEO!

Según su descripción, parece más un problema de red. Diagnosticar:

• Ejecute ssh con el parámetro -v para que sea detallado.
• Intente ejecutar un ping al servidor SSH al que se está conectando, y vea si esto también se bloquea al mismo tiempo.
• Intente algún otro tipo de transferencia al mismo servidor. Por ejemplo, wget con el parámetro --limit-rate para recuperar un archivo a través de HTTP y hacer que tarde lo suficiente como para que pueda desencadenar el comportamiento de "bloqueo".
• Vea si se cuelga solo cuando está inactivo, o incluso si está haciendo algo en este momento. Si se cuelga mientras está inactivo, el diagnóstico -v probablemente se lo dirá, en cuyo caso los consejos para usar keepalive podrían ayudar (ssh -o "TCPKeepAlive yes")

Si puede conectarse bien con Windows y PuTTY, probablemente no sea un problema del lado del servidor.

Si PermitEmptyPasswordy UsePAMson a la vez habilitado, el servidor OpenSSH siempre los intentos de autenticación con una contraseña nula, que se toma como una señal de que no se necesita ninguna autenticación para la cuenta en cuestión. Lo hace tan pronto como comienza el proceso de autenticación, en ambos protocolos, y no responde a ninguna solicitud de autenticación "real" del cliente. OpenSSH solo permitirá dicho acceso si se establece el indicador sshd_config PermitEmptyPassword; desafortunadamente, la forma en que se escribe el código, realiza la prueba de contraseña en cualquier caso y, por lo tanto, aparece en PAM como un error.

Entonces: deshabilite PermitEmptyPasswordo UsePAM, pero recuerde: sin PAM, no podrá iniciar sesión sin una clave.

Referencia: https://groups.google.com/forum/?fromgroups=#!topic/comp.security.ssh/wExY8lWlG-c

Creo que cuando inicias sesión, ubuntu ejecuta uno o más de estos archivos:

/etc/bash.bashrc
~/.bash_profile
~/.bashrc

Podrías ver lo que hay en ellos y tal vez incluso intentar ejecutarlos para ver qué lleva tanto tiempo.

En mi experiencia limitada, cuando la masilla funciona, pero Linux, Ubuntu en este caso, no, generalmente se mantiene viva. Los problemas de red o servidor afectarían a ambos SO cliente.

Puede usar la opción de mantener vivo anterior en la línea de comando, pero es un poco tedioso escribir.

Es más fácil editar algunos archivos de configuración.

Si tiene root access, y desea habilitarlo automáticamente para todos los usuarios, edite /etc/ssh/ssh_config, agregue

KeepAlive yes
ServerAliveInterval 120

Si no tiene acceso de root, o para habilitarlo para un solo usuario, edite ~/.ssh/configy agregue las mismas dos líneas.

Verifique los registros de su sistema en / var / log, puede encontrar un mensaje con el error / tiempo de espera relacionado.

Si también tienes tiempo espera antes

Editar /etc/sshd_config

y establecer (o agregar)

UseDNS no

o agregue su ip /etc/hostssi es una local estática

Es posible que desee intentar monitorear los procesos en ejecución mientras inicia sesión en el servidor desde una conexión ya iniciada (o una consola diferente). Existe la posibilidad de detectar qué procesos son los más activos o utilizan la mayor cantidad de CPU en ese momento.

A continuación se muestra un posible método:

1. Intenta iniciar sesión en otra consola.
2. Corre topallí para ver qué pasa.
3. Inicie sesión en la primera consola.

Tenga en cuenta que si el retraso no es causado por algún cálculo intensivo de CPU, no detectará nada fuera de lugar. En este caso, el problema podría estar vinculado a E / S (esperando alguna respuesta / lectura de red o disco)