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

Наконец-то я нашел решение:

1. sudo apt - удалите пейзаж-клиента-ландшафт-обычный
2. строка-комментарий. сессия необязательная pam_motd.so в /etc/pam.d/login и /etc/pam.d/sshd

Теперь вход ИНСТАНТ!

Если у вас еще есть время подождать, прежде чем

Отредактируйте / etc / sshd_config

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

UseDNS no

или добавьте свой IP в / etc / hosts , если это статический локальный

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

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

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

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

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

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

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

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

KeepAlive yes
ServerAliveInterval 120

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

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

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

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

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

У меня те же проблемы с 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 , похоже, запускается pam аутентификация через sshd.

Кажется, я это прибил!

Отключил pam_motd в следующих файлах:

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

One подробнее:

apt-get purge landscape-client landscape-common

Похоже, что они в определенной степени помогают. Хотя он только удаляет вредоносный сценарий в /etc/update-motd.d/ и не удаляет все сценарии в этом каталоге и не удаляет pam_motd либо.

В общем, я не нашел способа полностью отключить pam_motd , потому что, кажется, что бы он ни делал - это до некоторой степени замедляет процесс входа в систему. Он не блокируется, как сценарий в альбомной ориентации , но работает медленнее.

Отчет об ошибке по этой проблеме:

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

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

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

• закомментировать строку 'pam_motd' в /etc/pam.d/sshd , если вы не хотите отображать motd.
• удалите содержимое каталога /etc/update-motd.d .
• chmod -x сценарии в /etc/update-motd.d , которые вы не хотите запускать.

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

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

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

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

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

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