Длительное время ожидания при входе в систему

Когда я вхожу в систему на своем сервере, я получаю следующее:

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. 

Расширение этого ответа.

Мне удалось удаленно перезагрузить сервер и включить log-сервер DEBUG. Также воспользовалась этой возможностью, чтобы оставаться в системе и наблюдать за другими попытками входа в систему. Вот что происходит. Клиент подключается и авторизируется и зависает над сообщением выше.

На сервере список процессов показывает это:

 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 , он, похоже, запускается с помощью проверки подлинности pam через 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 , но медленнее.

Отчет об ошибке по этому вопросу:

Обходные пути оттуда:

Вы правы, что возможность входа в систему важнее, чем представление 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 комментариев session optional pam_motd.so в /etc/pam.d/login и /etc/pam.d/sshd

Теперь логин является МГНОВЕННЫМ!

Из вашего описания это больше похоже на сетевую проблему. Для диагностики:

  • Запустите ssh с параметром -v, чтобы он был подробным.
  • Попробуйте запустить пинг на SSH-сервер, к которому вы подключаетесь, и посмотреть, будет ли это также зависать одновременно.
  • Попробуйте другой способ передачи на тот же сервер. Например, wget с параметром -limit-rate для извлечения файла через HTTP и потребовать достаточно много времени, чтобы он мог вызвать «зависание» поведения.
  • Посмотрите, висит ли он только на холостом ходу или даже если вы делаете что-то в данный момент. Если он висит на холостом ходу, диагностика -v, вероятно, скажет вам об этом, и в этом случае помощь в использовании keepalive может помочь (ssh -o «TCPKeepAlive yes»)

Если вы можете подключиться OK с Windows и PuTTY, это, вероятно, не проблема на стороне сервера.

Я думаю, что когда вы входите в систему, ubuntu выполняет один или несколько из этих файлов:

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

Вы могли видеть, что в них, и, возможно, даже попытаться выполнить их, чтобы увидеть, что так долго.

В моем ограниченном опыте, когда шпатлевка работает, но Linux, Ubuntu в этом случае, нет, она обычно сохраняется. Проблемы с сетью или сервером повлияют на обе клиентские ОС.

Вы можете использовать приведенную выше опцию keep alive в командной строке, но это довольно утомительно для ввода.

Легче редактировать несколько файлов конфигурации.

Если у вас есть root access и вы хотите включить его автоматически для всех пользователей, отредактируйте /etc/ssh/ssh_config , добавьте

 KeepAlive yes ServerAliveInterval 120 

Если у вас нет доступа root или для его включения для одного пользователя, отредактируйте ~/.ssh/config и добавьте те же две строки.

Если PermitEmptyPassword и UsePAM включены, сервер OpenSSH всегда пытается UsePAM аутентификацию с пустым паролем, который требуется в качестве знака того, что для рассматриваемой учетной записи не требуется аутентификация. Он делает это, как только начинается процесс аутентификации, в обоих протоколах, а не в ответ на любой «реальный» запрос аутентификации от клиента. OpenSSH разрешает только такой доступ, если установлен флаг sshd_config PermitEmptyPassword ; к сожалению, способ написания кода, он выполняет тест пароля в любом случае и, таким образом, показывает PAM как сбой.

Итак: отключите PermitEmptyPassword или UsePAM , но помните: без PAM вы не сможете войти без ключа.

Ссылка: https://groups.google.com/forum/?fromgroups=#!topic/comp.security.ssh/wExY8lWlG-c

Проверьте свои системные журналы в / var / log, вы можете найти сообщение с соответствующей ошибкой / таймаутом.

Если у вас есть время ожидания до

Изменить /etc/sshd_config

и установить (или добавить)

 UseDNS no 

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

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

Ниже приведен один из возможных способов:

  1. Попробуйте войти в систему на другой консоли.
  2. Бегите top чтобы узнать, что произойдет.
  3. Войдите в систему на 1-й консоли.

Обратите внимание, что если задержка не вызвана некоторыми вычислениями с использованием ЦП, вы не заметите что-то не на месте. В этом случае проблема может быть связана с привязкой ввода / вывода (ожидая некоторого чтения / записи на диске или сетевого ответа).