Waktu tunggu yang lama saat masuk

Ketika saya masuk di server saya, saya mendapatkan ini:

No mail.
Last login: Fri Nov  5 14:22:45 2010...

maka saya harus menunggu selama 5 detik dan kemudian siap ...

wolfy@ubuntu-server:~$

Apakah ini waktu tunggu yang normal atau haruskah saya melakukan sesuatu untuk "memperbaiki" ini?

Ini biasanya merupakan hasil pam_motdregenerasi /etc/motdfile. Anda dapat memeriksa masing-masing skrip /etc/update-motd.duntuk melihat apakah ada sesuatu yang lambat.

Saya memiliki masalah yang sama dengan 10,04 (LTS).

Ketika saya menjalankan ssh -vvv, ia mati di:

debug1: Entering interactive session.

Memperluas jawaban ini.

Saya berhasil me-reboot server dari jarak jauh dan mengaktifkan DEBUG loggin. Juga menggunakan kesempatan ini untuk tetap masuk dan mengamati upaya masuk lainnya. Inilah yang terjadi. Klien menghubungkan dan diotorisasi dan hang di pesan di atas.

Di server, daftar proses menunjukkan ini:

root       835  0.0  0.1  11476  3348 ?        Ss   13:39   0:00 sshd: till [priv]
root       840  0.0  0.0   4804  1124 ?        S    13:39   0:00 /bin/sh -c /usr/bin/env -i PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin /bin/run-parts --lsbsysinit /etc/update-motd.d
root       841  0.0  0.0   4728  1108 ?        S    13:39   0:00 /bin/run-parts --lsbsysinit /etc/update-motd.d
root       854  0.0  0.0   4804  1144 ?        S    13:39   0:00 /bin/sh /etc/update-motd.d/50-landscape-sysinfo
root       861  0.2  0.5  15388  9248 ?        S    13:39   0:00 /usr/bin/python /usr/bin/landscape-sysinfo
root       863  0.0  0.0      0     0 ?        Z    13:39   0:00 [who] <defunct>

Saya dapat mengeksekusi dengan /usr/bin/python /usr/bin/landscape-sysinfobaik ketika saya login, tetapi untuk beberapa alasan, saya tidak tahu mengapa ini menghentikan proses login. Ketika saya mematikan proses, login berlanjut ke prompt dan berhasil .

Ini tampaknya bukan masalah ssh (d), ini lebih terkait dengan update-motddan lansekap. Saya menghapus update-motdpaket, tetapi sepertinya /etc/update-motddirektori masih ada dan skrip masih dieksekusi - menyebabkan proses hang.

Membahas ini lebih lanjut:

Ternyata /etc/update-motd.d/direktori tersebut tidak benar-benar milik paket update-motd, tampaknya dipicu oleh otentikasi pam melalui sshd.

Saya sepertinya berhasil!

Dinonaktifkan pam_motd dalam file berikut:

• /etc/pam.d/sshd
• /etc/pam.d/login

Satu lagi:

apt-get purge landscape-client landscape-common

Ini tampaknya membantu sampai batas tertentu. Meskipun, itu hanya menghapus skrip yang menyinggung /etc/update-motd.d/dan tidak menghapus semua skrip dalam direktori itu juga tidak menyingkirkan pam_motd.

Secara umum, saya tidak menemukan cara untuk menonaktifkan pam_motdsepenuhnya karena tampaknya, apa pun yang dilakukannya - memperlambat proses login hingga batas tertentu. Itu tidak memblokir seperti skrip landscape-common, tetapi lebih lambat.

Laporan bug tentang masalah ini:

• https://bugs.launchpad.net/ubuntu/+source/pam/+bug/805423

Penanganan masalah dari sana:

Anda benar bahwa kemampuan untuk masuk lebih penting daripada menyajikan motd. Jika perilaku ini merupakan masalah bagi Anda, ada beberapa cara untuk menonaktifkannya:

• beri komentar pada baris 'pam_motd' /etc/pam.d/sshdjika Anda tidak ingin menampilkan motd.
• hapus isi /etc/update-motd.ddirektori.
• chmod -x skrip /etc/update-motd.dyang tidak ingin Anda jalankan.

Akhirnya saya menemukan solusi:

1. sudo apt-get remove landscape-client landscape-common
2. baris komentar session optional pam_motd.so di /etc/pam.d/logindan/etc/pam.d/sshd

Sekarang login adalah INSTAN!

Dari uraian Anda, itu terdengar lebih seperti masalah jaringan. Untuk mendiagnosis:

• Jalankan ssh dengan parameter -v untuk menjadi verbose.
• Coba jalankan ping ke server SSH yang Anda sambungkan, dan lihat apakah ini juga hang pada saat yang sama.
• Coba beberapa jenis transfer lain ke server yang sama. Misalnya, wget dengan parameter --limit-rate untuk mengambil file melalui HTTP dan perlu waktu cukup lama sehingga dapat memicu perilaku "menggantung".
• Lihat apakah itu hang hanya saat idle, atau bahkan jika Anda sedang melakukan sesuatu saat ini. Jika hang saat idle, diagnostik -v mungkin akan memberi tahu Anda, dalam hal ini saran untuk menggunakan keepalive dapat membantu (ssh -o "TCPKeepAlive ya")

Jika Anda dapat menghubungkan OK dengan Windows dan Putty, itu mungkin bukan masalah di sisi server.

Jika PermitEmptyPassworddan UsePAMkeduanya diaktifkan, server OpenSSH selalu mencoba otentikasi dengan kata sandi nol, yang diperlukan sebagai tanda bahwa tidak diperlukan otentikasi untuk akun yang dimaksud. Ini melakukan ini segera setelah proses otentikasi dimulai, di kedua protokol, dan tidak menanggapi permintaan otentikasi "nyata" dari klien. OpenSSH hanya akan mengizinkan akses seperti itu jika flag sshd_config PermitEmptyPassworddiatur; Sayangnya, cara kode ditulis, ia melakukan tes kata sandi dalam hal apa pun, dan dengan demikian menunjukkan hingga PAM sebagai suatu kegagalan.

Jadi: nonaktifkan PermitEmptyPasswordatau UsePAM, tetapi ingat: tanpa PAM, Anda tidak akan bisa masuk tanpa kunci.

Referensi: https://groups.google.com/forum/?fromgroups=#!topic/comp.security.ssh/wExY8lWlG-c

Saya pikir ketika Anda login, ubuntu mengeksekusi satu atau lebih dari file-file ini:

/etc/bash.bashrc
~/.bash_profile
~/.bashrc

Anda dapat melihat apa yang ada di dalamnya dan mungkin bahkan mencoba mengeksekusi mereka untuk melihat apa yang memakan waktu begitu lama.

Dalam pengalaman saya yang terbatas, ketika dempul bekerja, tetapi Linux, Ubuntu dalam hal ini, tidak, biasanya tetap hidup. Masalah jaringan atau server akan memengaruhi kedua OS klien.

Anda dapat menggunakan opsi keep live di atas pada baris perintah, tetapi agak membosankan untuk mengetik.

Lebih mudah mengedit beberapa file konfigurasi.

Jika sudah root access, dan ingin mengaktifkannya secara otomatis untuk semua pengguna, edit /etc/ssh/ssh_config, tambah

KeepAlive yes
ServerAliveInterval 120

Jika Anda tidak memiliki akses root, atau untuk mengaktifkannya untuk satu pengguna, edit ~/.ssh/configdan tambahkan dua baris yang sama.

Periksa log sistem Anda di / var / log, Anda mungkin menemukan pesan dengan kesalahan / batas waktu terkait.

Jika Anda juga punya waktu tunggu sebelumnya

Edit /etc/sshd_config

dan mengatur (atau menambah)

UseDNS no

atau tambahkan ip Anda /etc/hostsjika yang lokal statis

Anda mungkin ingin mencoba memantau proses yang sedang berjalan saat Anda masuk ke server dari koneksi yang sudah masuk (atau konsol lain). Ada peluang untuk mengenali proses mana yang paling aktif atau menggunakan CPU terbanyak pada saat itu.

Di bawah ini adalah salah satu metode yang mungkin:

1. Cobalah masuk di konsol lain.
2. Larilah topke sana untuk melihat apa yang terjadi.
3. Masuk ke konsol 1.

Harap dicatat, bahwa jika penundaan itu bukan disebabkan oleh perhitungan intensif CPU, Anda tidak akan menemukan sesuatu yang tidak pada tempatnya. Kasus ini masalahnya mungkin I / O terikat (menunggu beberapa disk baca / tulis atau respons jaringan).