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

Question 1

Щелкните правой кнопкой мыши в любом месте на рабочем столе. Нажмите кнопку create launcher.

Type = application
Name = whatever you want it to be
Command = /usr/bin/gksu nautilus
Comments = whatever you want it to be

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

Помните, что вы можете заменить nautilus на свой любимый браузер, вы можете попробовать xfe, поэтому после dl команды xfe будет /usr/bin/gksu xfe. Если вы хотите создать OpenAs, вы можете вручную ввести любую программу, которую вы хотите запустить от имени root, Command = /usr/bin/gksu.

Question 2

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

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

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

Question 3

Question 4

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

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

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

Question 5

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

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

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

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

Question 6

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

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

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

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

  KeepAlive yes ServerAliveInterval 120

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

Question 7

Question 8

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

Question 9

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

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

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

   ИспользоватьDNS no

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

Question 10

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

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

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

Question 11

Наконец-то найдено решение:

sudo apt-get remove landscape-client landscape-common
comment line session optional pam_motd.so в /etc/pam.d/login и /etc/pam.d/sshd

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

Question 12

У меня такие же проблемы с 10.04 (LTS).

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

  debug1: ввод интерактивной сессии.

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

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

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

  root 835 0.0 0.1 11476 3348?  Ss 13:39 0:00 sshd: до [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] & lt; defunct & gt;

Я могу выполнить / 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 , потому что кажется, что бы он ни делал - это замедляет процесс входа в систему до определенной степени.

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

] 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 , которые вы не хотите запускать.

Savvas Radevic · Answer 1 · 13 August 2018 в 17:11

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

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

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

roadmr · Answer 2 · 13 August 2018 в 17:11

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

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

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

lgarzo · Answer 3 · 13 August 2018 в 17:11

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

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

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

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

наверх показывает это (при входе в систему): 12112 sshd 20 0 6988 856 412 S 13,9 0,1 0: 00,42 sshd — Wolfy, 5 November 2010 в 18:46
@Idi, я думаю, что это должен быть комментарий. — Tshepang, 6 November 2010 в 02:21

Panther · Answer 4 · 13 August 2018 в 17:11

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

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

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

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

  KeepAlive yes ServerAliveInterval 120

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

João Pinto · Answer 5 · 13 August 2018 в 17:11

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

Jorge Castro · Answer 6 · 13 August 2018 в 17:11

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

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

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

   ИспользоватьDNS no

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

Alessandro Pezzato · Answer 7 · 13 August 2018 в 17:11

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

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

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

Я добавил этот ответ на этот старый вопрос, потому что я столкнулся с той же проблемой (медленный вход в систему), но ничего здесь не решила моя проблема. Это мое решение. — Alessandro Pezzato, 2 October 2012 в 01:55

Jorge Castro · Answer 8 · 15 August 2018 в 23:48

Наконец-то найдено решение:

sudo apt-get remove landscape-client landscape-common
comment line session optional pam_motd.so в /etc/pam.d/login и /etc/pam.d/sshd

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

13

ответ дан Jorge Castro 15 August 2018 в 23:48

1

похоже, какая-то сетевая проблема удерживала статистику? – 0xF2 9 January 2013 в 01:06

Jorge Castro · Answer 9 · 19 August 2018 в 02:11

У меня такие же проблемы с 10.04 (LTS).

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

  debug1: ввод интерактивной сессии.

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

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

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

  root 835 0.0 0.1 11476 3348?  Ss 13:39 0:00 sshd: до [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] & lt; defunct & gt;

Я могу выполнить / 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 , потому что кажется, что бы он ни делал - это замедляет процесс входа в систему до определенной степени.

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

] 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 , которые вы не хотите запускать.

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

69 ответов

Другие вопросы по тегам:

Похожие вопросы: