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

20

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

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

, тогда я должен ждать 5 секунд, а затем готов ...

wolfy@ubuntu-server:~$

Является ли это время ожидания нормальным или я должен что-то сделать, чтобы «восстановить» это?

    
задан Wolfy 05.11.2010 в 14:57
источник

10 ответов

18

Обычно это результат pam_motd восстановления файла /etc/motd . Вы можете проверить отдельные скрипты в /etc/update-motd.d , чтобы увидеть, что что-то особенно медленное.

    
ответ дан Kees Cook 05.11.2010 в 21:33
источник
13

У меня такие же проблемы с 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

Еще одно:

apt-get purge landscape-client landscape-common

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

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

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

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

  

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

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

Нашел решение сам наконец:

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

Теперь логин INSTANT!

    
ответ дан BarsMonster 22.03.2011 в 06:12
4

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

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

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

    
ответ дан roadmr 08.12.2011 в 05:49
2

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

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

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

    
ответ дан Savvas Radevic 05.11.2010 в 16:30
2

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

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

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

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

KeepAlive yes
ServerAliveInterval 120

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

    
ответ дан Panther 08.12.2011 в 06:48
2

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

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

Ссылка: Ссылка

    
ответ дан Alessandro Pezzato 01.10.2012 в 22:53
0

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

    
ответ дан João Pinto 05.11.2010 в 15:14
0

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

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

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

UseDNS no

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

    
ответ дан user11187 21.02.2011 в 00:09
0

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

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

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

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

    
ответ дан ido 05.11.2010 в 15:17