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

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

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

Question 3

Question 4

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

Question 5

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

Question 6

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

Question 7

Question 8

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

Question 9

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

Question 10

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

Question 11

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

Question 12

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

Отладка этого: [ ! d10]

Оказывается, каталог /etc/update-motd.d/ на самом деле не принадлежит к пакету update-motd, он, похоже, запускается с помощью проверки подлинности pam через sshd.

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

/etc/pam.d/sshd /etc/pam.d/login [d19 ]

Еще один:

apt-get purge landscape-client landscape-common

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

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

Сообщение об ошибке по этой проблеме:

/etc/pam.d/sshd [ ! d17]

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

Вы правы, что возможность входа в систему важнее, чем представление motd. Если это поведение является для вас проблемой, есть несколько способов его отключения: закомментируйте строку «pam_motd» в /etc/pam.d/sshd, если вы не хотите отображать motd. удалите содержимое каталога /etc/update-motd.d. chmod -x скрипты в /etc/update-motd.d, которые вы не хотите запускать.

Question 13

Question 14

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

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

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

Question 15

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

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

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

Question 16

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

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

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

Question 17

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

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

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

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

KeepAlive yes
ServerAliveInterval 120

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

Question 18

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

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

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

Question 19

Question 20

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

Question 21

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

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

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

UseDNS no

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

Question 22

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

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

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

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

Question 23

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

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

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

Question 24

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

Question 25

Question 26

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

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

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

UseDNS no

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

Question 27

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

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

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

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

Question 28

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

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

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

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

KeepAlive yes
ServerAliveInterval 120

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

Question 29

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

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

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

Question 30

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

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

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

Question 31

Question 32

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

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

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

Question 33

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

Question 34

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

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

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

UseDNS no

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

Question 35

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

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

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

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

Question 36

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

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

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

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

KeepAlive yes
ServerAliveInterval 120

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

Question 37

Question 38

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

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

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

Kees Cook · Accepted Answer · 26 May 2018 в 00:35

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

18

ответ дан Kees Cook 26 May 2018 в 00:35

1

Brilliant. Это был файл 90-обновлений - доступный для меня. Также 50-ландшафт-sysinfo не самый быстрый. – Matt H 13 September 2013 в 05:16

Kees Cook · Accepted Answer · 25 July 2018 в 22:56

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

Kees Cook · Accepted Answer · 31 July 2018 в 11:38

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

Kees Cook · Accepted Answer · 2 August 2018 в 04:19

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

Kees Cook · Accepted Answer · 6 August 2018 в 04:24

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

Kees Cook · Accepted Answer · 7 August 2018 в 22:30

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

Kees Cook · Accepted Answer · 10 August 2018 в 10:38

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

Kees Cook · Accepted Answer · 13 August 2018 в 17:11

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

18

ответ дан Kees Cook 13 August 2018 в 17:11

1

Brilliant. Это был файл 90-обновлений - доступный для меня. Также 50-ландшафт-sysinfo не самый быстрый. – Matt H 13 September 2013 в 05:16

Jorge Castro · Answer 9 · 26 May 2018 в 00:35

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

Отладка этого: [ ! d10]

Оказывается, каталог /etc/update-motd.d/ на самом деле не принадлежит к пакету update-motd, он, похоже, запускается с помощью проверки подлинности pam через sshd.

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

/etc/pam.d/sshd /etc/pam.d/login [d19 ]

Еще один:

apt-get purge landscape-client landscape-common

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

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

Сообщение об ошибке по этой проблеме:

/etc/pam.d/sshd [ ! d17]

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

Вы правы, что возможность входа в систему важнее, чем представление motd. Если это поведение является для вас проблемой, есть несколько способов его отключения: закомментируйте строку «pam_motd» в /etc/pam.d/sshd, если вы не хотите отображать motd. удалите содержимое каталога /etc/update-motd.d. chmod -x скрипты в /etc/update-motd.d, которые вы не хотите запускать.

Jorge Castro · Answer 10 · 26 May 2018 в 00:35

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

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

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

10

ответ дан Jorge Castro 26 May 2018 в 00:35

1

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

roadmr · Answer 11 · 26 May 2018 в 00:35

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

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

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

Savvas Radevic · Answer 12 · 26 May 2018 в 00:35

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

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

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

Panther · Answer 13 · 26 May 2018 в 00:35

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

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

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

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

KeepAlive yes
ServerAliveInterval 120

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

Alessandro Pezzato · Answer 14 · 26 May 2018 в 00:35

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

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

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

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

João Pinto · Answer 15 · 26 May 2018 в 00:35

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

Jorge Castro · Answer 16 · 26 May 2018 в 00:35

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

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

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

UseDNS no

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

lgarzo · Answer 17 · 26 May 2018 в 00:35

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

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

Попробуйте войти в систему на другой консоли. Запустите 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

Alessandro Pezzato · Answer 18 · 25 July 2018 в 22:56

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

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

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

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

João Pinto · Answer 19 · 25 July 2018 в 22:56

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

Jorge Castro · Answer 20 · 25 July 2018 в 22:56

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

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

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

UseDNS no

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

0

ответ дан Jorge Castro 25 July 2018 в 22:56

1

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

lgarzo · Answer 21 · 25 July 2018 в 22:56

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

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

Попробуйте войти в систему на другой консоли. Запустите 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 22 · 25 July 2018 в 22:56

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

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

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

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

KeepAlive yes
ServerAliveInterval 120

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

roadmr · Answer 23 · 25 July 2018 в 22:56

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

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

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

Savvas Radevic · Answer 24 · 25 July 2018 в 22:56

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

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

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

Alessandro Pezzato · Answer 25 · 31 July 2018 в 11:38

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

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

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

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

João Pinto · Answer 26 · 31 July 2018 в 11:38

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

Jorge Castro · Answer 27 · 31 July 2018 в 11:38

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

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

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

UseDNS no

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

13

ответ дан Jorge Castro 31 July 2018 в 11:38

1

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

lgarzo · Answer 28 · 31 July 2018 в 11:38

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

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

Попробуйте войти в систему на другой консоли. Запустите 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 29 · 31 July 2018 в 11:38

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

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

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

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

KeepAlive yes
ServerAliveInterval 120

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

roadmr · Answer 30 · 31 July 2018 в 11:38

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

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

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

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

69 ответов

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

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