SSH lambat pada sesi awal

8

Memulai shell Interaktif melalui SSH lambat ke salah satu server saya. Segala sesuatu yang mengarah padanya termasuk negosiasi enkripsi cepat, tetapi kemudian hang selama 45 detik. Setelah itu, selesai dan saya memiliki shell. Bagaimana cara mengidentifikasi apa yang menggantung? Saya mencoba membersihkan lingkungan dan menonaktifkan semua penerusan jika itu memperlambat tetapi tidak membantu. Inilah perintah pengujian saya:

env -i ssh -x -a -vvv server

dan inilah output dari 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
sumber

unix.stackexchange.com/questions/10476/…

— forcefsck

@ Forcefsck Saya tidak berpikir posting itu relevan. Koneksi awal saya cepat, kunci bertukar, otentikasi cepat, tidak menunggu prompt kata sandi seperti pada posting di atas. Juga, semua DNS maju dan mundur harus diselesaikan pada titik ini saya cukup yakin. Juga, masalah ini tidak terputus-putus seperti pada posting di atas, setiap saat. Output verbose yang saya posting di atas dimulai tepat setelah pesan otentikasi berhasil. Saya pikir ini lebih sesuai dengan bash atau modul sesi pam yang lambat untuk memulai.

— penguin359

Apakah ada penundaan untuk sesi non-interaktif juga? Apakah ada penundaan ketika Anda memulai koneksi kedua saat satu sedang aktif? Metode otentikasi apa yang Anda gunakan? Apakah direktori rumah Anda diautomatiskan saat login dengan cara tertentu (jarak jauh atau terenkripsi)? Modul pam bisa menjadi penyebabnya, apa yang Anda miliki /etc/pam.d/sshd(atau bagaimanapun disebut pada sistem Anda)? Jika Anda memiliki akses ke log server, apakah ada yang relevan?

— Gilles 'SO- stop being evil'

@Gilles Ya, tampaknya memengaruhi perintah jarak jauh, scp, dan sftp. Jika Anda bermaksud dua koneksi SSH yang terpisah, keduanya lambat. Jika Anda bermaksud memulai sesi kedua melalui soket kontrol yang sama, saya baru saja mencobanya dan itu cepat, tapi saya mendapatkan peringatan tentang kegagalan xauth untuk mengunci .Xauthority. Saya menggunakan apa saja dari keyboard-interaktif, publickey, berbasis host, hingga gssapi-keyex. Otentikasi selalu cepat, meskipun kecepatannya sedikit berbeda. Direktori rumah saya bersifat lokal ke server dan tidak dienkripsi. PAM pada dasarnya adalah Ubuntu default + pam_krb5.so diinstal.

— penguin359

Anda mengatakan "lambat ke salah satu server saya". Apakah itu berperilaku normal saat mengisap ke mesin lain? Dan ini dari mesin rumah Anda, yang Anda masuk ke lokal? Apa OS pada lokal dan jarak jauh (termasuk versi)? Juga, apakah sshing dari server ke mesin di rumah Anda normal? Apakah sshing sebagai pengguna lain (baik lokal maupun jarak jauh) membuat perbedaan?

— Faheem Mitha

6

Dalam kasus yang sangat mirip, itu adalah salah satu skrip update-motd.

Berikut ini triknya:

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

Ini adalah pembantu kecil yang mengukur waktu setiap skrip:

$ 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
sumber

Terima kasih! Kebanyakan orang hanya menyarankan untuk mematikan DNS, tetapi login ssh saya masih lambat. Saya mulai menggali ke dalam proses login, dan jawaban Anda menunjuk saya ke /etc/update-motd.d/50-landscape-sysinfo, yang tampaknya lambat.

— Rennex

1

ini sangat membantu - bagi saya pembunuhnya 50-landscape-sysinfo. Dan fyi, Anda bisa chmod -x /etc/update-motd.d/90-updates-availablemencegahnya mengeksekusi saat login daripada menghapusnya sama sekali.

— billynoah

3

pam_krb5.so dikonfigurasikan untuk memperoleh token AFS untuk shell yang tidak ada yang memiliki batas waktu 30 detik menghentikan segala otentikasi menggunakan modul itu, bukan hanya SSH. Dihapus itu dan otentikasi terjadi jauh lebih cepat.

— penguin359
sumber

2

Jika server ssh Anda telah mengaktifkan pemetaan balik DNS, itu bisa menjadi penyebab penundaan, cari VerifyReverseMappingdi /etc/ssh/sshd_configfile server.

— Frederik Deweerdt
sumber

1

Saya pikir pemetaan DNS terbalik terjadi sebelum otentikasi diizinkan untuk berhasil, tetapi saya akan mengujinya.

— penguin359

Saya pikir maksud Anda UseDNS, saya mendapat peringatan penyusutan pada VerifyReverseMapping. Bagaimanapun juga, saya menetapkan keduanya untuk tidak dan itu tidak membantu. Saya benar-benar memastikan pemetaan terbalik saya benar dan host dapat memetakan nama host klien saya ke catatan A dan kembali lagi tanpa masalah.

— penguin359

0

Saya memiliki masalah yang sama, tetapi tampaknya disebabkan oleh sesuatu yang lain. Solusinya:

/etc/ssh/sshd_config:
#UsePAM yes

dan:

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

— Ole Tange
sumber