Giriş sırasında uzun bekleme süresi

Sunucumda oturum açtığımda şunu alıyorum:

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

o zaman 5 saniye beklemeliyim ve sonra hazırım ...

wolfy@ubuntu-server:~$

Bekleme süresi normal mi, yoksa bunu onarmak için bir şey mi yapmalıyım?

Bu genellikle dosyayı pam_motdyeniden oluşturmanın sonucudur /etc/motd. Bir /etc/update-motd.dşeyin özellikle yavaş olup olmadığını görmek için ayrı ayrı komut dosyalarını kontrol edebilirsiniz .

10.04 (LTS) ile de aynı sorunları yaşıyorum.

Ben ssh'ımı çalıştırdığımda -vvvölüyor:

debug1: Entering interactive session.

Bu cevabı genişletmek.

Sunucuyu uzaktan yeniden başlatmayı başardım ve DEBUG girişini etkinleştirdim. Bu fırsatı, giriş yapmak ve diğer giriş denemelerini gözlemlemek için de kullandı. İşte olan şey. Müşteri bağlanır ve yetkilendirilir ve yukarıdaki mesajda kilitlenir.

Sunucuda, işlem listesi şunu gösterir:

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>

Giriş yaptıktan sonra /usr/bin/python /usr/bin/landscape-sysinfogayet iyi bir şekilde yürüttüm , ancak nedense giriş işleminin neden durduğunu anlayamıyorum. Süreci öldürdüğümde, giriş istemine devam ediyor ve başarılı .

Bu bir ssh (d) problemi gibi görünmüyor, daha çok update-motdpeyzajla ilgili . update-motdPaketi kaldırdım , ancak /etc/update-motddizin devam ediyor gibi görünüyor ve komut dosyaları hala yürütülüyor - işlemin askıda kalmasına neden oluyor.

Bu hata ayıklama:

Dışarı Dönüşler /etc/update-motd.d/dizinine gerçekten pakete ait değil update-motd, sshd yoluyla Pam kimlik doğrulaması tarafından tetiklenen gibi görünüyor.

Çivilenmiş gibiyim!

Aşağıdaki dosyalarda pam_motd etkisizleştirildi:

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

Bir tane daha:

apt-get purge landscape-client landscape-common

Bunlar belirli bir süreye yardımcı olacak gibi görünüyor. Yine de, yalnızca rahatsız edici betiği kaldırır ve /etc/update-motd.d/bu dizindeki tüm komut dosyalarını siler veya silinmez pam_motd.

Genel olarak, pam_motdtamamen devre dışı bırakmanın bir yolunu bulamadım çünkü göründüğü gibi, ne yaparsa yapsın - giriş sürecini belirli bir süreye yavaşlatıyor. Komut dosyası gibi engellemiyor landscape-common, ancak daha yavaş.

Bu konuda hata raporu:

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

Oradan geçici çözümler:

Giriş yapma kabiliyetinin bir sloganı sunmaktan daha önemli olduğu konusunda haklısın. Bu davranış sizin için bir sorunsa, devre dışı bırakmanın birkaç yolu vardır:

• /etc/pam.d/sshdBir motd göstermek istemiyorsanız 'pam_motd' satırını yorumlayın.
• /etc/update-motd.ddizinin içeriğini silmek
• chmod -x içinde /etc/update-motd.dçalıştırmak istemediğin komut dosyalarını .

Sonunda kendime çözüm buldum:

1. sudo apt-get remove landscape-client landscape-common
2. Yorum satır session optional pam_motd.so içinde /etc/pam.d/loginve/etc/pam.d/sshd

Şimdi giriş yapın ANINDA!

Açıklamasından bir ağ problemi gibi geliyor. Teşhis etmek:

• Ssh'yi ayrıntılı olacak -v parametresiyle çalıştırın.
• Bağlandığınız SSH sunucusuna ping çalıştırmayı deneyin ve aynı zamanda da takılıp kalmayacağına bakın.
• Aynı sunucuya başka tür bir aktarım yapmayı deneyin. Örneğin, bir dosyayı HTTP üzerinden almak ve - "asılı" davranışını tetikleyebilecek kadar uzun sürmesini sağlamak için --limit-rate parametresiyle wget yapın.
• Boşta mı yoksa şu anda bir şey yapıyor olsanız bile, asıldığını görün. Boştayken takılırsa, -v diagnostiği muhtemelen size söyleyecektir, bu durumda keepalive kullanmak için tavsiyeler yardımcı olabilir (ssh -o "TCPKeepAlive yes")

Tamam'ı Windows ve PuTTY ile bağlayabiliyorsanız, bu muhtemelen sunucu tarafında bir sorun değildir.

Eğer PermitEmptyPasswordve UsePAMikisi de etkindir, OpenSSH sunucusu her zaman hiçbir kimlik doğrulama söz konusu hesap için gerekli olduğunun bir işareti olarak alır boş şifre ile kimlik doğrulaması çalışır. Her iki protokolde de kimlik doğrulama işlemi başlar başlamaz bunu yapar ve istemciden gelen herhangi bir "gerçek" kimlik doğrulama talebine cevap vermez. OpenSSH, yalnızca sshd_config bayrağı PermitEmptyPasswordayarlanmışsa bu erişime izin verecektir ; ne yazık ki, kodun yazıldığı gibi, her durumda parola sınamasını gerçekleştirir ve bu nedenle PAM'a bir başarısızlık olduğunu gösterir.

Yani: devre dışı bırakınPermitEmptyPassword ya da UsePAMunutmayın: PAM olmadan, anahtar olmadan giriş yapamazsınız.

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

Sanırım giriş yaptığınızda, ubuntu bu dosyalardan birini veya daha fazlasını yürütür:

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

İçlerinde ne olduğunu görebiliyordu ve belki de çok uzun sürecek olanı görmek için onları çalıştırmayı deneyebilirsin.

Sınırlı tecrübeme göre, macun çalıştığında, ancak Linux, bu durumda Ubuntu, çalışmıyor, genellikle hayatta kalıyor. Ağ iletişimi veya sunucu sorunları her iki istemci işletim sistemini de etkiler.

Komut satırında yukarıdaki canlı tutma seçeneğini kullanabilirsiniz, ancak yazmak biraz sıkıcıdır.

Birkaç yapılandırma dosyasını düzenlemek daha kolaydır.

Eğer varsa root accessve tüm kullanıcıların, düzenleme için otomatik olarak etkin hale getirmek istiyorsanız /etc/ssh/ssh_config, eklenti

KeepAlive yes
ServerAliveInterval 120

Kök erişiminiz yoksa veya bunu tek bir kullanıcı için etkinleştiremiyorsanız ~/.ssh/config, aynı iki satırı düzenleyin ve ekleyin.

Sistem günlüklerinizi / var / log adresinde kontrol edin, ilgili hata / zaman aşımı ile ilgili bir mesaj bulabilirsiniz.

Eğer vaktiniz varsa önce bekleyin

Düzenle /etc/sshd_config

ve ayarla (veya ekle)

UseDNS no

ya da /etc/hostssabit bir yerelse , ip'inizi ekleyin

Sunucuya önceden giriş yapmış bir bağlantıdan (veya farklı bir konsoldan) giriş yaparken, çalışan işlemleri izlemeyi deneyebilirsiniz. Hangi süreçlerin en aktif olduğunu ya da o zaman en fazla CPU kullananı bulma şansı var.

Aşağıda olası bir yöntem var:

1. Başka bir konsolda giriş yapmayı deneyin.
2. topNe olduğunu görmek için oraya koş .
3. 1. konsoldan giriş yapın.

Lütfen dikkat, gecikme CPU yoğun bir hesaplamadan kaynaklanmadıysa, hiçbir şeyi yerinde görmeyeceğinizi unutmayın. Bu durumda sorun G / Ç'ye bağlı olabilir (bazı disk okuma / yazma veya ağ yanıtı bekleniyor).