Molto tempo di attesa all'accesso

20

Quando accedo al mio server ottengo questo:

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

quindi devo aspettare 5 secondi e poi è pronto ...

wolfy@ubuntu-server:~$

Questo tempo di attesa è normale o dovrei fare qualcosa per "riparare" questo?

    
posta Wolfy 05.11.2010 - 14:57
fonte

10 risposte

18

Di solito è il risultato di pam_motd che rigenera il file /etc/motd . Puoi controllare i singoli script in /etc/update-motd.d per vedere se qualcosa è particolarmente lento.

    
risposta data Kees Cook 05.11.2010 - 21:33
fonte
13

Ho gli stessi problemi con 10.04 (LTS).

Quando eseguo il mio ssh con -vvv , muore a:

debug1: Entering interactive session.

Estensione di questa risposta.

Sono riuscito a riavviare il server da remoto e ho abilitato l'accesso a DEBUG. Utilizzato anche questa opportunità per rimanere connesso e osservare altri tentativi di accesso. Ecco cosa succede. Il client si connette ed è autorizzato e si blocca al messaggio precedente.

Sul server, l'elenco dei processi mostra questo:

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>

Posso eseguire /usr/bin/python /usr/bin/landscape-sysinfo bene mentre sono loggato, ma per qualche ragione, non riesco a capire perché stalli il processo di login. Quando cancello il processo, l'accesso continua al prompt ed è riuscito .

Questo non sembra essere un problema ssh (d), è più correlato a update-motd e landscape. Ho disinstallato il pacchetto update-motd , ma sembra che la directory /etc/update-motd persista e gli script siano ancora eseguiti, causando il blocco del processo.

Debuging ulteriormente:

Risulta che la directory /etc/update-motd.d/ non appartiene veramente al pacchetto update-motd , sembra essere attivata dall'autenticazione della Pam tramite sshd.

Mi sembra di averlo inchiodato!

Disabilitato pam_motd nei seguenti file:

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

Un altro:

apt-get purge landscape-client landscape-common

Questi sembrano aiutare in una certa misura. Tuttavia, solo rimuove lo script incriminato in /etc/update-motd.d/ e non elimina tutti gli script in quella directory né elimina anche pam_motd .

In generale, non ho trovato alcun modo per disabilitare pam_motd completamente perché sembra, qualunque cosa faccia, rallenta il processo di login fino a un certo punto. Non blocca come lo script in landscape-common , ma è più lento.

Rapporto bug su questo problema:

Soluzioni alternative da qui:

  

Hai ragione che la possibilità di accedere è più importante di   presentando un motd. Se questo comportamento è un problema per te, ci sono   diversi modi per disattivarlo:

     
  • commenta la riga "pam_motd" in /etc/pam.d/sshd se non vuoi visualizzare un motd.
  •   
  • elimina il contenuto della directory /etc/update-motd.d .
  •   
  • chmod -x gli script in /etc/update-motd.d che non vuoi eseguire.
  •   
    
risposta data Till 11.07.2012 - 15:20
fonte
10

Finalmente trovato la soluzione:

  1. sudo apt-get remove landscape-client landscape-common
  2. linea di commento %codice% in session optional pam_motd.so e /etc/pam.d/login

Ora il login è INSTANT!

    
risposta data BarsMonster 22.03.2011 - 06:12
fonte
4

Dalla tua descrizione sembra più un problema di rete. Per diagnosticare:

  • Esegui ssh con il parametro -v per essere dettagliato.
  • Prova a eseguire un ping sul server SSH a cui ti stai connettendo, e vedi se anche questo si blocca allo stesso tempo.
  • Prova qualche altro tipo di trasferimento allo stesso server. Ad esempio, wget con il parametro --limit-rate per recuperare un file tramite HTTP e farlo richiedere abbastanza tempo da attivare il comportamento "sospeso".
  • Controlla se si blocca solo quando è inattivo, o anche se stai facendo qualcosa al momento. Se si blocca mentre è inattivo, la diagnostica -v probabilmente ti dirà così, nel qual caso il consiglio di usare keepalive potrebbe aiutare (ssh -o "TCPKeepAlive sì")

Se riesci a connetterti OK con Windows e PuTTY, probabilmente non è un problema dal lato del server.

    
risposta data roadmr 08.12.2011 - 05:49
fonte
2

Penso che quando esegui il login, ubuntu esegue uno o più di questi file:

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

Potresti vedere cosa c'è dentro e magari provare ad eseguirli per vedere cosa ci sta mettendo così tanto tempo.

    
risposta data Savvas Radevic 05.11.2010 - 16:30
fonte
2

Nella mia limitata esperienza, quando il putty funziona, ma Linux, in questo caso Ubuntu, no, di solito è mantenuto in vita. I problemi di rete o del server influenzerebbero entrambi i sistemi operativi client.

Puoi usare l'opzione keep alive sopra sulla riga di comando, ma è un po 'noioso da digitare.

Più facile per modificare alcuni file di configurazione.

Se hai root access e desideri attivarlo automaticamente per tutti gli utenti, modifica /etc/ssh/ssh_config , aggiungi

KeepAlive yes
ServerAliveInterval 120

Se non hai accesso root o per abilitarlo per un singolo utente, modifica ~/.ssh/config e aggiungi le stesse due righe.

    
risposta data Panther 08.12.2011 - 06:48
fonte
2

Se PermitEmptyPassword e UsePAM sono entrambi abilitati, il server OpenSSH tenta sempre l'autenticazione con una password nulla, che prende come segno che non è necessaria alcuna autenticazione per l'account in questione. Lo fa non appena inizia il processo di autenticazione, in entrambi i protocolli, e non in risposta a nessuna richiesta di autenticazione "reale" dal cliente. OpenSSH consentirà tale accesso solo se sshd_config flag PermitEmptyPassword è impostato; sfortunatamente, il modo in cui è il codice scritto, esegue il test della password in ogni caso, e quindi mostra fino a PAM come errore.

Quindi: disabilita PermitEmptyPassword o UsePAM , ma ricorda: senza PAM, non sarai in grado di accedere senza una chiave.

Riferimento: link

    
risposta data Alessandro Pezzato 01.10.2012 - 22:53
fonte
0

Controlla i log di sistema in / var / log, potresti trovare un messaggio con il relativo errore / timeout.

    
risposta data João Pinto 05.11.2010 - 15:14
fonte
0

Se hai anche un tempo di attesa prima

Modifica /etc/sshd_config

e imposta (o aggiungi)

UseDNS no

o aggiungi il tuo IP in /etc/hosts se è locale statico

    
risposta data user11187 21.02.2011 - 00:09
fonte
0

Si potrebbe voler provare a monitorare i processi in esecuzione mentre si sta effettuando l'accesso al server da una connessione già connessa (o una console diversa). C'è la possibilità di individuare quali processi sono i più attivi o di utilizzare la maggior parte della CPU in quel momento.

Di seguito è riportato un possibile metodo:

  1. Prova ad accedere su un'altra console.
  2. Esegui top lì per vedere cosa succede.
  3. Accedi alla 1a console.

Si noti che, se il ritardo non è causato da un calcolo intensivo della CPU, non si individuerà nulla di fuori posto. In questo caso il problema potrebbe essere legato all'I / O (in attesa di qualche lettura / scrittura del disco o risposta di rete).

    
risposta data ido 05.11.2010 - 15:17
fonte

Leggi altre domande sui tag