la connessione ssh impiega un'eternità per iniziare, bloccata su "pledge: network"

44

La connessione a uno dei miei server tramite SSH richiede più di 20 secondi per l'avvio.

Questo non è correlato alle condizioni LAN o WAN, poiché la connessione a se stesso accetta lo stesso (ssh localhost). Dopo che la connessione è stata stabilita, è super veloce interagire con il server.

L'uso di -vvv mostra che la connessione è bloccata dopo aver detto "pledge: network". A questo punto, l'autenticazione (qui utilizzando la chiave) è già stata eseguita, come visibile qui:

...
debug1: Authentication succeeded (publickey).
Authenticated to myserver.mydomain.com ([xx.xx.xx.xx]:22).
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network

(... bloccato qui da 15 a 25 secondi ...)

debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug2: callback start
debug2: fd 3 setting TCP_NODELAY
debug2: client_session2_setup: id 0
...

Il server è Ubuntu 16.04. Mi è già successo in passato con un altro server (era Ubuntu 12.04), il server ha trovato la soluzione e il problema è scomparso dopo un po '...

sshd_config è quello predefinito fornito da Ubuntu.

Finora ho provato:

usando -o GSSAPIAuthentication = no nel comando ssh
utilizzando la password anziché una chiave
usando UsePrivilegeSeparation no invece di yes, in sshd_config

ssh

— M-Jack
fonte

1

Di solito per me le connessioni SSH lente sono problemi DNS, potrebbe essere il caso qui? Ad esempio, il server potrebbe essere bloccato tentando di eseguire un DNS inverso per l'IP del client e attendere che

— scada il

In realtà no: per impostazione predefinita UseDNS non è definito in sshd_config e la pagina man dice che questa opzione è "no" per impostazione predefinita.

— M-Jack,

3

Alcuni googling suggeriscono che ciò può essere causato dall'aggiornamento di systemd senza riavviare. E c'è stato un aggiornamento di systemd per xenial il 12 luglio . systemctl restart systemd-logindrisolve il problema solo per un breve periodo di tempo per me.

— Ivan Kozik,

O se stai vedendo pam_systemd(sshd:session): Failed to create session: Connection timed outcome indicato in una risposta, potrebbe essere github.com/systemd/systemd/issues/2925

— Ivan Kozik,

Sono venuto qui dopo aver riscontrato questo problema dopo un aggiornamento, e il suggerimento di @ IvanKozik ha risolto il problema - vale a dire il riavvio di systemctl systemd-logind - quindi grazie per quello.

— Paul M,

43

Questo è probabilmente un problema con D-Buse systemd. Se il dbusservizio viene riavviato per qualche motivo, dovrai anche riavviare systemd-logind.

Puoi verificare se questo è il problema aprendo il registro demone ssh (su Ubuntu dovrebbe essere /var/log/auth.log) e controllare se ha queste righe:

sshd[2721]: pam_systemd(sshd:session): Failed to create session: Connection timed out

Se sì, riavvia il systemd-logindservizio:

systemctl restart systemd-logind

Ho avuto lo stesso problema su CentOS 7, perché è messagebusstato riavviato (che è come D-Busviene chiamato il servizio su CentOS).

— Strahinja Kustudic
fonte

Ho provato a riavviare systemd-logind ma dopo un po 'si dice che il demone PolicyKit si è disconnesso dal bus. Non siamo più un agente di autenticazione registrato. Il processo per systemd-logind.service non è riuscito perché è stato superato un timeout. Vedere "status systemctl systemd-logind.service" e "journalctl -xe" per i dettagli.

— Kun Ren,

@KunRen probabilmente dovrai riavviare il polkitservizio usando systemctl restart polkit.

— Strahinja Kustudic,

16

trovato la risposta:

ha cambiato UsePAM da yes a no nel file sshd_config

Dopo aver riavviato il servizio ssh, la connessione è ora immediata al server. Su questo server, PAM è collegato a ldap, quindi questo è probabilmente il motivo, anche se qui mi sto collegando con un utente dichiarato sul server stesso, non su LDAP.

Bene, questo è più un modo per aggirare il problema, non proprio una soluzione ... Ho altri server impostati allo stesso modo che non hanno questo problema.

Spero che questo possa aiutare qualcuno ...

— M-Jack
fonte

1

la modifica di UsePAM in no ha altri effetti. Vedi questa discussione Quindi ho dovuto impostare una password per l'utente, perché ho riscontrato errori come i nagios dell'utente non consentiti perché l'account è bloccato

— M-Jack,

4

Questa non è davvero una buona idea.

— Jakuje,

1

perché ?? qualche alternativa?

— M-Jack,

8

Il PAM viene utilizzato per altre cose relative alla gestione degli account nei sistemi moderni. Invece di spegnerlo, faresti meglio a indagare su cosa sta succedendo nello stack PAM e perché impiega così tanto tempo.

— Jakuje,

Lasciare un modulo PAM molto inutilizzato abilitato per l'accesso SSH è un buco nella sicurezza. Limitare l'accesso a servizi critici come SSH dal punto di vista della sicurezza è sempre una buona idea anche per QUALSIASI altro servizio. Quando vuoi che il modulo PAM collabori con SSH? Ad esempio: quando è necessario integrarlo con active directory tramite winbind, quando sono necessari due fattori di autenticazione con i token di Google, ecc. In altri casi (quando si utilizzano passwd e shadow), disattivarlo è perfettamente sicuro. Ogni utente di PAM vedrà questo: cve.mitre.org/cgi-bin/cvekey.cgi?keyword=pam

— Michal Sokolowski,

10

Questo è successo su due dei miei server Fedora 25 ed è stato causato da molti tentativi falliti di accesso a SSH.

(I suggerimenti comuni sull'utilizzo GSSAPIAuthentication=noe UseDNS=no, o sul riavvio systemd-logind, non hanno fatto alcuna differenza.)

Su questi server, /etc/pam.d/postlogincontiene:

session     optional      pam_lastlog.so silent noupdate showfailed

La pagina man di pam_lastlogspiega che l' showfailedopzione:

Visualizza il numero di tentativi di accesso falliti e la data dell'ultimo tentativo fallito da btmp.

Su questi server, i /var/log/btmpfile erano enormi a causa di molti tentativi di accesso falliti. I btmpfile di registro non venivano ruotati sia.

Ho installato il logrotatepacchetto per assicurarmi che i file di registro vengano ruotati in futuro. (Su Fedora, la configurazione fornita con logrotategestisce la rotazione di /var/log/btmp.)

Ho anche eliminato gli enormi btmpfile di registro; non appena ho fatto questo, la connessione ai server è stata di nuovo istantanea.

— Richard Fearn
fonte

Questo ha risolto il mio problema! Grazie. Bella presa. SSH impiegava 5-10 secondi, e ora è meno di un battito di ciglia. Questo è su una macchina virtuale che ho connesso a Internet pubblico per anni. Le sue regole del firewall potrebbero probabilmente essere leggermente migliorate, ora che ci penso. Per altri, questo è tutto ciò che ho fatto: sudo truncate -s 0 /var/log/btmp- Il mio aveva una dimensione di 2,7 G.

— Carl Bennett,

2

Nel mio caso il motivo era un rsyslogd in crash. L'ho scoperto perché non c'erano più messaggi di log in es. / Var / log / syslog o /var/log/mail.log

Quindi service rsyslog restartrisolto il problema per noi.

— randomcontrol
fonte

Stessa causa su un nostro server che esegue CentOS 6.10. Il riavvio di rsyslog se ne è occupato. Il fatto è che non era morto. Funzionava, ma apparentemente non faceva nulla di utile.

— UtahJarhead,

1

Per me questo problema è causato da file di grandi dimensioni (centinaia di MB) btmp. Questo file registra i tentativi di accesso. Quando le persone stanno cercando di forzare la tua password, questo file può essere grande e causare ritardi nella "pledge: network"fase.

Prova a cancellare il file di registro

echo "" > /var/log/btmp

e vedere se aiuta.

— Marek Nagy
fonte

3

Ciò richiede molte più spiegazioni. Per i principianti, perché pensi che sia utile?

— Sven

suggerimento: la semplice digitazione :> /var/log/btmpfa lo stesso tra l'altro.

— Marius

1

Per me la soluzione stava aggiungendo

UseDNS no

alla /etc/ssh/sshd_confige poi, naturalmente, service ssh restart(sul nostro server Debian / Jessie). Nient'altro...

prima :

ssh git@git.*****.de true  0.03s user 0.01s system 0% cpu 13.440 total
ssh git@git.*****.de true  0.03s user 0.01s system 0% cpu 20.990 total
ssh git@git.*****.de true  0.03s user 0.02s system 0% cpu 31.114 total
ssh git@git.*****.de true  0.03s user 0.01s system 0% cpu 25.898 total

dopo :

ssh git@git.*****.de true  0.03s user 0.02s system 5% cpu 0.832 total
ssh git@git.*****.de true  0.03s user 0.01s system 7% cpu 0.523 total
ssh git@git.*****.de true  0.03s user 0.01s system 7% cpu 0.574 total

— tamasgal
fonte

No, l'aggiunta UseDNS noè una soluzione per un problema completamente diverso.

— Kasperd,

@kasperd Non importa. Nel mio caso ho avuto gli stessi sintomi (brevemente: bloccato dopo aver detto "impegno: rete") e questo è ciò che alla fine ha aiutato, quindi questa è una soluzione per almeno un problema molto simile e sono sicuro che aiuterà uno o altro ad un certo punto.

— tamasgal,

Lo stesso qui, due blocchi durante la connessione, uno dopo sign_and_send_pubkey, uno più lungo dopo pledge: network. L'aggiunta solo UseDNS nocon successive service ssh restartha risolto il problema su una vecchia installazione di Ubuntu 14.04.5 LTS qui.

— Hound

0

Ho notato la seguente riga nel mio feedback di debug:

Control socket connect(/var/lib/jenkins/.ssh/USER@HOST:22): Permission denied

Che era un file di proprietà di root:rootmentre io lo sono jenkins. La rimozione di questo file ha risolto i miei problemi.

— Ambidex
fonte