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"?
server
ssh
performance
login
Wolfy
fuente
fuente
Respuestas:
Esto suele ser el resultado de la
pam_motd
regeneración del/etc/motd
archivo. Puede verificar las secuencias de comandos individuales/etc/update-motd.d
para ver si algo es especialmente lento.fuente
Tengo los mismos problemas con 10.04 (LTS).
Cuando ejecuto mi ssh con
-vvv
, muere a las: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:
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 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-motd
paisaje. Desinstalé elupdate-motd
paquete, pero parece que el/etc/update-motd
directorio 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 paqueteupdate-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:
Uno mas:
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 eliminapam_motd
.En general, no encontré ninguna manera de deshabilitarlo
pam_motd
completamente porque parece, lo que sea que haga, ralentiza el proceso de inicio de sesión hasta cierto punto. No se bloquea como el scriptlandscape-common
, pero es más lento.Informe de error sobre este tema:
Soluciones a partir de ahí:
fuente
Finalmente encontré la solución:
sudo apt-get remove landscape-client landscape-common
session optional pam_motd.so
en/etc/pam.d/login
y/etc/pam.d/sshd
¡Ahora iniciar sesión es INSTANTÁNEO!
fuente
Según su descripción, parece más un problema de red. Diagnosticar:
Si puede conectarse bien con Windows y PuTTY, probablemente no sea un problema del lado del servidor.
fuente
Si
PermitEmptyPassword
yUsePAM
son 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_configPermitEmptyPassword
; 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
PermitEmptyPassword
oUsePAM
, 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
fuente
Creo que cuando inicias sesión, ubuntu ejecuta uno o más de estos archivos:
Podrías ver lo que hay en ellos y tal vez incluso intentar ejecutarlos para ver qué lleva tanto tiempo.
fuente
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
, agregueSi no tiene acceso de root, o para habilitarlo para un solo usuario, edite
~/.ssh/config
y agregue las mismas dos líneas.fuente
Verifique los registros de su sistema en / var / log, puede encontrar un mensaje con el error / tiempo de espera relacionado.
fuente
Si también tienes tiempo espera antes
Editar
/etc/sshd_config
y establecer (o agregar)
o agregue su ip
/etc/hosts
si es una local estáticafuente
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:
top
allí para ver qué pasa.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)
fuente