koneksi ssh membutuhkan waktu lama untuk memulai, terjebak di "pledge: network"

Koneksi ke salah satu server saya menggunakan ssh membutuhkan waktu lebih dari 20 detik untuk memulai.

Ini tidak terkait dengan kondisi LAN atau WAN, karena koneksi ke dirinya sendiri memerlukan hal yang sama (ssh localhost). Setelah koneksi akhirnya didirikan, sangat cepat untuk berinteraksi dengan server.

Menggunakan -vvv menunjukkan bahwa koneksi macet setelah mengucapkan "pledge: network". Pada titik ini, otentikasi (menggunakan kunci di sini) sudah dilakukan, seperti terlihat di sini:

...
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 [email protected]
debug1: Entering interactive session.
debug1: pledge: network

(... terjebak di sini selama 15 hingga 25 detik ...)

debug1: client_input_global_request: rtype [email protected] want_reply 0
debug2: callback start
debug2: fd 3 setting TCP_NODELAY
debug2: client_session2_setup: id 0
...

Server adalah Ubuntu 16.04. Itu sudah terjadi pada saya di masa lalu dengan server lain (adalah Ubuntu 12,04), nerver menemukan solusi dan masalahnya menghilang setelah beberapa saat ...

sshd_config adalah default yang disediakan oleh Ubuntu.

Sejauh ini saya sudah mencoba:

• menggunakan -o GSSAPIAuthentication = no pada perintah ssh
• menggunakan kata sandi alih-alih kunci
• menggunakan UsePrivilegeSeparation no bukan yes, di sshd_config

Ini mungkin masalah dengan D-Busdan systemd. Jika dbuslayanan di-restart karena beberapa alasan, Anda juga harus memulai kembali systemd-logind.

Anda dapat memeriksa apakah ini masalahnya dengan membuka ssh daemon log (seharusnya di Ubuntu /var/log/auth.log) dan memeriksa apakah ada baris berikut:

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

Jika ya, cukup restart systemd-logindlayanan:

systemctl restart systemd-logind

Saya memiliki masalah yang sama pada CentOS 7 ini, karena messagebussudah dimulai ulang (begitulah cara D-Buslayanan dipanggil pada CentOS).

menemukan jawabannya:

mengubah UsePAM dari yes menjadi no di file sshd_config

Setelah memulai kembali layanan ssh, koneksi sekarang langsung ke server. Di server ini, PAM ditautkan ke ldap, jadi mungkin itulah alasannya, bahkan jika di sini saya terhubung dengan pengguna yang dideklarasikan di server itu sendiri, bukan yang LDAP.

Nah, ini lebih merupakan cara untuk mem-bypass masalah, bukan solusi ... Saya punya server lain yang mengatur cara yang sama yang tidak mengalami masalah ini.

Semoga ini bisa membantu seseorang ...

Ini terjadi pada dua dari server Fedora 25 saya, dan disebabkan oleh banyak upaya login SSH yang gagal.

(Saran umum untuk menggunakan GSSAPIAuthentication=nodan UseDNS=no, atau memulai kembali systemd-logind, tidak membuat perbedaan.)

Di server ini, /etc/pam.d/postloginmengandung:

session     optional      pam_lastlog.so silent noupdate showfailed

Halaman manual untuk pam_lastlogmenjelaskan bahwa showfailedopsi akan:

Tampilkan jumlah upaya gagal login dan tanggal upaya gagal terakhir dari btmp.

Pada server ini, /var/log/btmpfile-file itu sangat besar karena banyak upaya login gagal. File btmplog juga tidak diputar.

Saya menginstal logrotatepaket untuk memastikan file log akan diputar di masa depan. (Pada Fedora, konfigurasi yang dikirimkan dengan logrotatemenangani rotasi /var/log/btmp.)

Saya juga menghapus btmpfile-file log yang sangat besar ; segera setelah saya melakukan ini, menyambungkan ke server seketika lagi.

Dalam kasus saya alasannya adalah rsyslogd macet. Saya menemukan ini karena tidak ada lagi log-pesan di eg / var / log / syslog atau /var/log/mail.log

Jadi, service rsyslog restartselesaikan masalah bagi kami.

Bagi saya masalah ini disebabkan oleh btmpfile besar (ratusan MB) . File ini mencatat upaya login. Ketika orang-orang mencoba memaksakan kata sandi Anda, file ini dapat menjadi besar dan menyebabkan keterlambatan "pledge: network"fase.

Coba hapus file log

echo "" > /var/log/btmp

dan lihat apakah itu membantu.

Bagi saya solusinya adalah menambahkan

UseDNS no

ke /etc/ssh/sshd_configdan kemudian tentu saja service ssh restart(di server Debian / Jessie kami). Tidak ada lagi...

sebelum :

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

setelah :

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

Saya perhatikan baris berikut dalam umpan balik debug saya:

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

Yang merupakan file yang dimiliki root:rootsaat saya jenkins. Menghapus file ini menyelesaikan masalah saya.