Largo tiempo de espera al iniciar sesión

20

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 este tiempo de espera normal o debería hacer algo para "repararlo"?

    
pregunta Wolfy 05.11.2010 - 13:57

10 respuestas

18

Suele ser el resultado de que pam_motd regenere el archivo /etc/motd . Puede verificar los scripts individuales en /etc/update-motd.d para ver si algo es especialmente lento.

    
respondido por el Kees Cook 05.11.2010 - 20:33
13

Tengo los mismos problemas con 10.04 (LTS).

Cuando ejecuto mi ssh con -vvv , muere en:

debug1: Entering interactive session.

Extendiendo esta respuesta.

Logré reiniciar el servidor de forma remota y habilité el reinicio de DEPURACIÓN. También usé esta oportunidad para permanecer conectado y observar otros intentos de inicio de sesión. Esto es lo que sucede. 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-sysinfo bien mientras estoy conectado, pero por alguna razón, no puedo entender por qué detiene el proceso de inicio de sesión. Cuando elimino el proceso, el inicio de sesión continúa en el prompt y es exitoso .

Esto no parece ser un problema ssh (d), está más relacionado con update-motd y landscape. Desinstalé el paquete update-motd , pero parece que el directorio /etc/update-motd persiste y las secuencias de comandos todavía se ejecutan, lo que hace que el proceso se cuelgue.

Depurar esto más:

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

¡Parece que lo he clavado!

Desactivado pam_motd en los siguientes archivos:

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

Uno más:

apt-get purge landscape-client landscape-common

Estos parecen ayudar en cierta medida. Sin embargo, solo elimina la secuencia de comandos ofensiva en /etc/update-motd.d/ y tampoco elimina todas las secuencias de comandos en ese directorio, ni tampoco elimina pam_motd .

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

Informe de error sobre este problema:

Soluciones provisionales desde allí:

  

Tiene razón en que la capacidad de iniciar sesión es más importante que   presentando una motd. Si este comportamiento es un problema para ti, hay   varias formas en que puede desactivarlo:

     
  • comente la línea 'pam_motd' en /etc/pam.d/sshd si no desea mostrar un motd.
  •   
  • eliminar los contenidos del directorio /etc/update-motd.d .
  •   
  • chmod -x los scripts en /etc/update-motd.d que no desea ejecutar.
  •   
    
respondido por el Till 11.07.2012 - 13:20
10

Encontré la solución yo mismo finalmente:

  1. sudo apt-get remove landscape-client landscape-common
  2. línea de comentario %código% en session optional pam_motd.so y /etc/pam.d/login

¡Ahora el inicio de sesión es INSTANTE!

    
respondido por el BarsMonster 22.03.2011 - 05:12
4

Según su descripción, parece más un problema de red. Para 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 cuelga al mismo tiempo.
  • Intente otro tipo de transferencia al mismo servidor. Por ejemplo, wget con el parámetro --limit-rate para buscar un archivo a través de HTTP y demorarlo lo suficiente como para que pueda desencadenar el comportamiento "colgado".
  • 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 diga, en cuyo caso los consejos para usar keepalive podrían ayudar (ssh -o "TCPKeepAlive yes")

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

    
respondido por el roadmr 08.12.2011 - 04:49
2

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 e incluso intentar ejecutarlos para ver qué tarda tanto.

    
respondido por el Savvas Radevic 05.11.2010 - 15:30
2

En mi experiencia limitada, cuando la masilla funciona, pero Linux, Ubuntu en este caso, no, por lo general se mantienen vivos. Los problemas de red o del servidor afectarían a ambos SO del cliente.

Puede utilizar la opción de mantener activo anterior en la línea de comandos, pero es un poco tedioso escribir.

Más fácil de 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 administrador, o para habilitarlo para un solo usuario, edite ~/.ssh/config y agregue las mismas dos líneas.

    
respondido por el Panther 08.12.2011 - 05:48
2

Si PermitEmptyPassword y UsePAM están habilitados, el servidor OpenSSH siempre intenta la autenticación con una contraseña nula, que toma como una señal de que no se necesita autenticación para la cuenta en cuestión. Hace esto tan pronto como comienza el proceso de autenticación, en ambos protocolos, y no en respuesta a ninguna solicitud de autenticación "real" del cliente OpenSSH solo permitirá dicho acceso si el sshd_config flag PermitEmptyPassword está establecido; desafortunadamente, la forma en que el código es escrito, realiza la prueba de contraseña en cualquier caso, y así se muestra hasta PAM como un fracaso.

Entonces, desactive PermitEmptyPassword o UsePAM , pero recuerde: sin PAM, no podrá iniciar sesión sin una clave.

Referencia: enlace

    
respondido por el Alessandro Pezzato 01.10.2012 - 20:53
0

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

    
respondido por el João Pinto 05.11.2010 - 14:14
0

Si también tiene una espera de tiempo antes de

Editar /etc/sshd_config

y establecer (o agregar)

UseDNS no

o agregue su ip en /etc/hosts si es una local estática

    
respondido por el user11187 20.02.2011 - 23:09
0

Es posible que desee intentar supervisar 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 usan la mayor cantidad de CPU en ese momento.

A continuación hay un posible método:

  1. Intenta iniciar sesión en otra consola.
  2. Ejecute top allí para ver qué sucede.
  3. Inicie sesión en la primera consola.

Tenga en cuenta que si el retraso no se debe a un cálculo intensivo de la CPU, no detectará nada fuera de lugar. En este caso, el problema podría estar vinculado a E / S (esperando alguna respuesta de lectura / escritura del disco o red).

    
respondido por el ido 05.11.2010 - 14:17

Lea otras preguntas en las etiquetas