Tempo di attesa lungo per l'accesso

Quando accedo al mio server ottengo questo:

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

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

wolfy@ubuntu-server:~$

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

Questo di solito è il risultato della pam_motdrigenerazione del /etc/motdfile. Puoi controllare i singoli script /etc/update-motd.dper vedere se qualcosa è particolarmente lento.

Ho gli stessi problemi con 10.04 (LTS).

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

debug1: Entering interactive session.

Estendere questa risposta.

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

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-sysinfobene mentre sono connesso, ma per qualche motivo, non riesco a capire perché blocca il processo di accesso. Quando interrompo il processo, l'accesso continua al prompt e ha esito positivo .

Questo non sembra essere un problema ssh (d), è più legato update-motde paesaggistico. Ho disinstallato il update-motdpacchetto, ma sembra che la /etc/update-motddirectory persista e gli script siano ancora eseguiti, causando il blocco del processo.

Debug ulteriore:

Si scopre che la /etc/update-motd.d/directory non appartiene davvero al pacchetto update-motd, sembra essere innescata dall'autenticazione pam tramite sshd.

Mi sembra di averlo inchiodato!

Pam_motd disabilitato nei seguenti file:

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

Ancora uno:

apt-get purge landscape-client landscape-common

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

In generale, non ho trovato alcun modo per disabilitare pam_motdcompletamente perché sembra, qualunque cosa faccia - rallenta il processo di accesso a un certo limite. Non si blocca come lo script landscape-common, ma è più lento.

Segnalazione di bug su questo problema:

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

Soluzioni alternative da lì:

Hai ragione sul fatto che la possibilità di accedere è più importante della presentazione di un motd. Se questo comportamento è un problema per te, esistono diversi modi per disabilitarlo:

• commentare la riga "pam_motd" /etc/pam.d/sshdse non si desidera visualizzare un motd.
• elimina il contenuto della /etc/update-motd.ddirectory.
• chmod -x gli script in /etc/update-motd.dcui non si desidera eseguire.

Finalmente ho trovato la soluzione:

1. sudo apt-get remove landscape-client landscape-common
2. riga di commento session optional pam_motd.so in /etc/pam.d/logine/etc/pam.d/sshd

Ora il login è ISTANTANEO!

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

• Esegui ssh con il parametro -v per essere prolisso.
• 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 sullo stesso server. Ad esempio, wget con il parametro --limit-rate per recuperare un file tramite HTTP e impiegare il tempo necessario per attivare il comportamento "sospeso".
• Vedi se si blocca solo quando è inattivo o anche se stai facendo qualcosa al momento. Se si blocca mentre è inattivo, la diagnostica -v probabilmente lo dirà, nel qual caso i consigli per usare keepalive potrebbero essere d'aiuto (ssh -o "TCPKeepAlive yes")

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

Se PermitEmptyPassworde UsePAMsono entrambi abilitati, il server OpenSSH tenta sempre l'autenticazione con una password nulla, il che indica 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 risponde a nessuna richiesta di autenticazione "reale" dal client. OpenSSH consentirà tale accesso solo se PermitEmptyPasswordè impostato il flag sshd_config ; sfortunatamente, il modo in cui il codice viene scritto, esegue comunque il test della password e quindi si presenta a PAM come un errore.

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

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

Penso che quando accedi, Ubuntu esegue uno o più di questi file:

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

Potresti vedere cosa c'è dentro e forse anche provare a eseguirli per vedere cosa ci vuole così tanto tempo.

Nella mia esperienza limitata, quando lo stucco funziona, ma Linux, in questo caso Ubuntu no, di solito viene mantenuto in vita. I problemi di rete o server influirebbero su entrambi i sistemi operativi client.

È possibile utilizzare l'opzione precedente keep alive sulla riga di comando, ma è un po 'noioso da digitare.

Più facile da modificare alcuni file di configurazione.

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

KeepAlive yes
ServerAliveInterval 120

Se non si dispone dell'accesso root o per abilitarlo per un singolo utente, modificare ~/.ssh/confige aggiungere le stesse due righe.

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

Se hai anche un tempo, aspetta prima

modificare /etc/sshd_config

e imposta (o aggiungi)

UseDNS no

o aggiungi il tuo IP /etc/hostsse è locale statico

È possibile che si desideri provare a monitorare i processi in esecuzione mentre si accede al server da una connessione già connessa (o da un'altra console). C'è la possibilità di individuare quali processi sono più attivi o che utilizzano la maggior parte della CPU in quel momento.

Di seguito è riportato un metodo possibile:

1. Prova ad accedere su un'altra console.
2. Corri toplì per vedere cosa succede.
3. Accedi alla prima console.

Si noti che se il ritardo non è causato da alcuni calcoli ad alta intensità di CPU, non si noterà nulla fuori posto. In questo caso il problema potrebbe essere associato a I / O (in attesa di lettura / scrittura del disco o risposta di rete).