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

44

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 no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network

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

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
...

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

ssh

— M-Jack
sumber

1

Biasanya bagi saya koneksi SSH lambat adalah masalah DNS, mungkin itu yang terjadi di sini? Sebagai contoh, server mungkin macet mencoba melakukan DNS terbalik untuk IP klien dan menunggu waktu habis

— Eric Renouf

Sebenarnya tidak: secara default UseDNS tidak didefinisikan dalam sshd_config dan halaman manual mengatakan bahwa opsi ini "tidak" secara default.

— M-Jack

3

Beberapa Googling menyarankan ini dapat disebabkan oleh memperbarui systemd tanpa me-reboot. Dan ada pembaruan systemd untuk xenial pada 12 Juli . systemctl restart systemd-logindmemperbaiki masalah hanya untuk jangka waktu singkat bagi saya.

— Ivan Kozik

Atau jika Anda melihat pam_systemd(sshd:session): Failed to create session: Connection timed outseperti yang disebutkan dalam jawaban, ini mungkin github.com/systemd/systemd/issues/2925

— Ivan Kozik

Saya datang ke sini setelah memiliki masalah ini setelah pembaruan, dan saran @ IvanKozik memperbaiki masalah - yaitu systemctl restart systemd-logind - jadi terima kasih untuk itu.

— Paul M

43

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).

— Strahinja Kustudic
sumber

Saya mencoba untuk me-restart systemd-logind tetapi setelah beberapa saat ia mengatakan daemon PolicyKit terputus dari bus. Kami bukan lagi agen otentikasi terdaftar. Pekerjaan untuk systemd-logind.service gagal karena batas waktu terlampaui. Lihat "systemctl status systemd-logind.service" dan "journalctl -xe" untuk detailnya.

— Kun Ren

@KunRen Anda mungkin perlu me-restart polkitlayanan menggunakan systemctl restart polkit.

— Strahinja Kustudic

16

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 ...

— M-Jack
sumber

1

mengubah UsePAM menjadi tidak memiliki efek lain. Lihat diskusi ini Jadi saya harus menetapkan kata sandi untuk pengguna, karena saya mendapat kesalahan seperti Pengguna nagios tidak diizinkan karena akun terkunci

— M-Jack

4

Ini benar-benar bukan ide yang bagus.

— Jakuje

1

kenapa ?? ada alternatif?

— M-Jack

8

PAM digunakan untuk hal-hal lain di sekitar manajemen akun dalam sistem modern. Daripada mematikannya, Anda sebaiknya menyelidiki apa yang sedang terjadi di tumpukan PAM dan mengapa itu memakan waktu begitu lama.

— Jakuje

Meninggalkan modul PAM yang sangat tidak umum yang diaktifkan untuk akses SSH adalah lubang keamanan. Membatasi akses ke layanan penting seperti SSH dari sudut pandang keamanan selalu merupakan ide bagus untuk APAPUN layanan lainnya juga. Kapan Anda ingin modul PAM bekerja sama dengan SSH? Sebagai contoh: ketika Anda perlu mengintegrasikannya dengan direktori aktif melalui winbind, ketika Anda memerlukan dua faktor auth dengan google token, dll. Dalam kasus lain (ketika menggunakan passwd dan shadow) mematikannya sangat aman. Setiap pengguna PAM akan melihat ini: cve.mitre.org/cgi-bin/cvekey.cgi?keyword=pam

— Michal Sokolowski

10

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.

— Richard Fearn
sumber

Ini menyelesaikan masalah saya! Terima kasih. Tangkapan bagus. SSH butuh 5-10 detik, dan sekarang kurang dari sekejap mata. Ini pada VM yang saya hubungkan ke Internet publik selama bertahun-tahun. Aturan firewallnya mungkin bisa disetel sedikit lebih baik, sekarang saya sudah memikirkannya. Bagi yang lain, ini yang saya lakukan: sudo truncate -s 0 /var/log/btmp- Ukuran tambang saya 2.7G.

— Carl Bennett

2

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.

— kontrol acak
sumber

Penyebab yang sama pada server kita yang menjalankan CentOS 6.10. Restart rsyslog merawatnya. Masalahnya, itu tidak mati. Itu berjalan, tetapi tampaknya tidak melakukan apa pun yang berguna.

— UtahJarhead

1

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.

— Marek Nagy
sumber

3

Ini membutuhkan lebih banyak penjelasan. Sebagai permulaan, menurut Anda mengapa ini membantu?

— Sven

tip: Hanya mengetik :> /var/log/btmpmelakukan btw yang sama.

— Marius

1

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

— tamasgal
sumber

Tidak, menambahkan UseDNS noadalah solusi untuk masalah yang sama sekali berbeda.

— kasperd

@kasperd Tidak masalah. Dalam kasus saya, saya memiliki gejala yang sama (sebentar: macet setelah mengatakan "janji: jaringan") dan inilah yang akhirnya membantu, jadi ini adalah solusi untuk setidaknya masalah yang sangat mirip dan saya yakin itu akan membantu satu atau lebih lain di beberapa titik.

— tamasgal

Sama di sini, dua hang selama koneksi, satu setelah sign_and_send_pubkey, yang lebih lama setelah pledge: network. Menambahkan hanya UseDNS nodengan berikutnya service ssh restarttidak menyelesaikan masalah pada instalasi Ubuntu 14.04.5 LTS lama di sini.

— Hound

0

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.

— Ambidex
sumber