SSH lento all'inizio della sessione

8

L'avvio di una shell interattiva su SSH è lento per uno dei miei server. Tutto ciò che lo conduce, inclusa la negoziazione della crittografia, è veloce, ma si blocca per 45 secondi. Dopodiché, finisce e ho una shell. Come faccio a identificare a cosa pende? Ho provato a cancellare l'ambiente e disabilitare tutti gli inoltri nel caso in cui questo lo stesse rallentando, ma non ha aiutato. Ecco il mio comando di prova:

env -i ssh -x -a -vvv server

ed ecco l'output di SSH:

debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
*(hangs for 45 seconds here)*
debug3: Wrote 128 bytes for a total of 3191
debug2: callback start
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug1: Sending environment.

— penguin359
fonte

unix.stackexchange.com/questions/10476/…

— forcefsck

@forcefsck Non penso che il post sia rilevante. La mia connessione iniziale è veloce, le chiavi si scambiano, l'autenticazione è veloce, nessuna attesa su una richiesta di password come nel post sopra. Inoltre, tutti i DNS forward e reverse dovrebbero essere finiti a questo punto, ne sono abbastanza certo. Inoltre, questo problema non è intermittente come nel post sopra, è ogni volta. L'output dettagliato che ho pubblicato sopra inizia subito dopo il messaggio di autenticazione riuscita. Penso che sia più sulla falsariga di bash o che un modulo di sessione pam sia lento da avviare.

— penguin359,

C'è un ritardo anche per le sessioni non interattive? C'è un ritardo quando si avvia una seconda connessione mentre una è attiva? Quale metodo di autenticazione usi? La tua home directory è stata montata automaticamente all'accesso in qualche modo (remoto o crittografato)? Un modulo pam potrebbe essere il colpevole, cosa hai /etc/pam.d/sshd(o comunque è chiamato sul tuo sistema)? Se hai accesso ai registri del server, c'è qualcosa di rilevante?

— Gilles 'SO- smetti di essere malvagio' il

@Gilles Sì, sembra influenzare i comandi remoti, scp e sftp. Se intendi due connessioni SSH separate, entrambe sono lente. Se intendi avviare una seconda sessione attraverso lo stesso socket di controllo, l'ho appena provato ed è veloce, ma ricevo un avviso sull'errore di xauth nel bloccare .Xauthority. Uso qualsiasi cosa, da tastiera interattiva, chiave pubblica, basata su host, a gssapi-keyex. L'autenticazione è sempre veloce a prescindere, anche se la velocità varia leggermente. La mia home directory è locale sul server e non crittografata. PAM è essenzialmente Ubuntu predefinito + pam_krb5.so installato.

— penguin359,

Dici "lento a uno dei miei server". Si comporta normalmente quando si lancia su altre macchine? E questo viene dal tuo computer di casa, a cui sei connesso localmente? Che cos'è il sistema operativo su locale e remoto (compresa la versione)? Inoltre, lo sshing dal server al tuo computer di casa è normale? Lo sshing come altro utente (sia locale che remoto) fa differenza?

— Faheem Mitha,

6

In un caso molto simile, era uno degli script update-motd.

Il seguente ha fatto il trucco:

sudo rm /etc/update-motd.d/90-updates-available

Ecco un piccolo aiuto che misura il tempo di ogni sceneggiatura:

$ for f in /etc/update-motd.d/*;do echo $f;time $f;done
/etc/update-motd.d/00-header            0m0.007s
/etc/update-motd.d/10-help-text         0m0.005s
/etc/update-motd.d/90-updates-available 0m49.163s
/etc/update-motd.d/91-release-upgrade   0m0.152s
/etc/update-motd.d/98-fsck-at-reboot    0m0.015s
/etc/update-motd.d/98-reboot-required   0m0.003s
(output reduced to the relevant parts)

— Daniel Alder
fonte

Grazie! Molte persone consigliano semplicemente di disattivare il DNS, ma il mio login ssh era ancora lento. Ho iniziato a scavare nel processo di accesso e la tua risposta mi ha indirizzato a /etc/update-motd.d/50-landscape-sysinfo, che sembrava essere lento.

— Rennex,

1

questo è davvero utile - per me l'assassino è stato 50-landscape-sysinfo. E a proposito, puoi semplicemente chmod -x /etc/update-motd.d/90-updates-availableimpedire che venga eseguito all'accesso invece di rimuoverlo del tutto.

— Billynoah,

3

pam_krb5.so è stato configurato per acquisire token AFS per una shell inesistente che aveva un timeout di 30 secondi che interrompeva qualsiasi autenticazione usando quel modulo, non solo SSH. Rimosso e l'autenticazione avviene molto più rapidamente.

— penguin359
fonte

2

Se il tuo server ssh ha attivato la mappatura DNS inversa, potrebbe essere la causa del ritardo, cerca VerifyReverseMappingnel /etc/ssh/sshd_configfile del server.

— Frederik Deweerdt
fonte

1

Pensavo che la mappatura DNS inversa fosse avvenuta prima che l'autenticazione potesse avere successo, ma lo proverò.

— penguin359,

Penso che intendi UseDNS, ho ricevuto un avviso deprezzato su VerifyReverseMapping. Indipendentemente da ciò, ho impostato entrambi su no e non ha aiutato. Mi prendo cura di assicurarmi che la mia mappatura inversa sia corretta e che l'host possa mappare il nome host del mio cliente su un record A e viceversa senza alcun problema.

— penguin359,

0

Ho avuto lo stesso problema, ma apparentemente causato da qualcos'altro. La soluzione:

/etc/ssh/sshd_config:
#UsePAM yes

e:

sudo /etc/init.d/ssh stop;sudo /etc/init.d/ssh start;

— Ole Tange
fonte