Долгое время ожидания при входе

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

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.

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

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

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

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, но он медленнее.

Сообщение об ошибке по этому вопросу:

• 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 yes")

Если вы можете подключиться нормально с 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

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

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

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

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

Если у вас есть 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-ую консоль.

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