Довгий час очікування на вході

Коли я входжу на свій сервер, я отримую таке:

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

тоді я повинен почекати 5 секунд і тоді готовий ...

wolfy@ubuntu-server:~$

Це нормальний час очікування чи я повинен щось зробити, щоб "відремонтувати" це?

Зазвичай це результат pam_motdрегенерації /etc/motdфайлу. Ви можете перевірити окремі сценарії, /etc/update-motd.dщоб побачити, чи відбувається щось особливо повільно.

У мене такі ж проблеми з 10.04 (LTS).

Коли я запускаю свій ssh -vvv, він гине при:

debug1: Entering interactive session.

Подовження цієї відповіді.

Мені вдалося дистанційно перезавантажити сервер і включив DEBUG loggin. Також використовували цю можливість залишатись увійти та спостерігати за іншими спробами входу. Ось що відбувається. Клієнт підключається і має авторизацію та зависає на вищезгадане повідомлення.

На сервері список процесів показує це:

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>

Я можу виконати /usr/bin/python /usr/bin/landscape-sysinfoвідмінно під час свого входу, але я чомусь не можу зрозуміти, чому він зупиняє процес входу. Коли я вбиваю процес, вхід продовжує підказувати і проходить успішно .

Це, здається, не є ssh (d) проблемою, воно більше пов'язане з update-motdландшафтом. Я видалив update-motdпакунок, але здається, що /etc/update-motdкаталог зберігається, а сценарії все ще виконуються - це призводить до зависання процесу.

Налаштування цього далі:

Виявляється, /etc/update-motd.d/каталог насправді не належить до пакету update-motd, він, здається, запускається автентифікацією пам’яті через sshd.

Я, здається, це прибив!

Вимкнено pam_motd у таких файлах:

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

Ще один:

apt-get purge landscape-client landscape-common

Вони, здається, допомагають певною мірою. Хоча він видаляє лише скрипт, що порушує правила, /etc/update-motd.d/і не видаляє всі сценарії в цьому каталозі, а також не позбавляється від нього pam_motd.

Взагалі я не знайшов способу pam_motdповністю відключити, оскільки, здається, що б це не робилося - це сповільнює процес входу до певного розширення. Він не блокується як сценарій у landscape-common, але це повільніше.

Звіт про помилку щодо цього питання:

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

Обхідні шляхи звідти:

Ви маєте рацію, що здатність входити в систему є важливішою, ніж представлення motd. Якщо така поведінка для вас є проблемою, ви можете вимкнути її декількома способами:

• прокоментуйте рядок 'pam_motd', /etc/pam.d/sshdякщо ви не хочете показувати motd.
• видалити вміст /etc/update-motd.dкаталогу.
• chmod -x сценарії, /etc/update-motd.dякі ви не хочете запускати.

Нарешті я знайшов рішення:

1. sudo apt-get remove landscape-client landscape-common
2. рядок коментарів session optional pam_motd.so у /etc/pam.d/loginта/etc/pam.d/sshd

Тепер логін НЕ МІСТЬ!

З вашого опису це звучить більше як проблема з мережею. Для діагностики:

• Запустіть ssh з параметром -v, який буде багатослівним.
• Спробуйте запустити ping до SSH-сервера, до якого ви підключаєтесь, і перевірте, чи він одночасно зависає.
• Спробуйте інший вид передачі на той же сервер. Наприклад, wget з параметром --limit-rate для отримання файлу через HTTP і потребує цього достатньо часу, щоб він міг викликати поведінку "висить".
• Подивіться, чи зависає вона лише в режимі очікування або навіть якщо ви зараз щось робите. Якщо він висить у режимі очікування, -v діагностика, ймовірно, скаже вам так, і в цьому випадку порада використовувати keepalive може допомогти (ssh -o "TCPKeepAlive так")

Якщо ви можете підключити OK з Windows та PuTTY, це, мабуть, не проблема з боку сервера.

Якщо PermitEmptyPasswordі UsePAMобидва включені, сервер OpenSSH завжди намагається встановити автентифікацію з нульовим паролем, який приймає як знак того, що для вказаного облікового запису не потрібна автентифікація. Це робиться, як тільки починається процес аутентифікації в обох протоколах, а не у відповідь на будь-який "реальний" запит аутентифікації від клієнта. OpenSSH дозволить такий доступ, лише якщо встановлено прапор sshd_config PermitEmptyPassword; на жаль, спосіб написання коду, він у будь-якому випадку виконує перевірку пароля і, таким чином, відображає PAM як збій.

Отже: відключити PermitEmptyPasswordабо UsePAM, але пам’ятайте: без PAM ви не зможете увійти без ключа.

Довідка: https://groups.google.com/forum/?fromgroups=#!topic/comp.security.ssh/wExY8lWlG-c

Я думаю, що коли ви входите в систему, ubuntu виконує один або кілька таких файлів:

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

Ви можете побачити, що в них, і, можливо, навіть спробувати виконати їх, щоб побачити, що забирає так довго.

За моїм обмеженим досвідом, коли шпаклівка працює, але Linux, Ubuntu в цьому випадку, ні, це зазвичай залишається в живих. Проблеми з мережею або сервером можуть вплинути на обидві ОС клієнта.

Ви можете використовувати вищезгаданий параметр "залишатися в живих" у командному рядку, але це набридливо.

Простіше редагувати кілька файлів конфігурації.

Якщо у вас є root accessі хочете ввімкнути це автоматично для всіх користувачів, відредагуйте /etc/ssh/ssh_config, додайте

KeepAlive yes
ServerAliveInterval 120

Якщо у вас немає кореневого доступу або щоб увімкнути його для одного користувача, відредагуйте ~/.ssh/configта додайте ті самі два рядки.

Перевірте системні журнали за адресою / var / log, ви можете знайти повідомлення із пов’язаною помилкою / тайм-аутом.

Якщо у вас також є час, зачекайте раніше

Редагувати /etc/sshd_config

і встановити (або додати)

UseDNS no

або додайте свій ip в, /etc/hostsякщо його статичний локальний

Можливо, ви захочете спробувати контролювати запущені процеси під час входу на сервер за допомогою вже входу в систему (або іншої консолі). Є можливість виявити, які процеси є найактивнішими або використовують найбільш процесор на той час.

Нижче наведено один із можливих методів:

1. Спробуйте увійти на іншу консоль.
2. Біжи topтуди, щоб побачити, що відбувається.
3. Увійдіть на 1-й консолі.

Зауважте, що якщо затримка не спричинена деяким обчислювальним процесором, ви нічого не помітите на місці. У цьому випадку проблема може бути пов'язана з введенням-виведенням (очікування деякого читання / запису диска або відповідь мережі).