Когда я вхожу в систему на моем сервере, я получаю это:
No mail.
Last login: Fri Nov 5 14:22:45 2010...
тогда я должен ждать 5 секунд, а затем готов ...
wolfy@ubuntu-server:~$
Это время ожидания нормальное или я должен что-то сделать, чтобы «починить» это?
server
ssh
performance
login
Волчок
источник
источник
Ответы:
Обычно это результат
pam_motd
восстановления/etc/motd
файла. Вы можете проверить отдельные сценарии,/etc/update-motd.d
чтобы увидеть, если что-то особенно медленно.источник
У меня такие же проблемы с 10.04 (LTS).
Когда я запускаю свой SSH с
-vvv
, он умирает в:Расширяя этот ответ.
Мне удалось перезагрузить сервер удаленно и включил журнал отладки. Также использовал эту возможность, чтобы оставаться в системе и наблюдать за другими попытками входа. Вот что происходит. Клиент подключается и авторизуется и зависает в сообщении выше.
На сервере список процессов показывает это:
Я могу выполнять все
/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/update-motd.d/
и не удаляет все сценарии в этом каталоге, а также не удаляет ихpam_motd
.В общем, я не нашел способа
pam_motd
полностью отключить, потому что, кажется, что бы он ни делал - это до некоторой степени замедляет процесс входа в систему. Он не блокируется как скриптlandscape-common
, но он медленнее.Сообщение об ошибке по этому вопросу:
Обходные пути оттуда:
источник
Сам наконец нашел решение:
sudo apt-get remove landscape-client landscape-common
session optional pam_motd.so
в/etc/pam.d/login
и/etc/pam.d/sshd
Теперь логин МГНОВЕННО!
источник
Из вашего описания это больше похоже на проблемы с сетью. Чтобы диагностировать:
Если вы можете подключиться нормально с Windows и PuTTY, это, вероятно, не проблема на стороне сервера.
источник
Если
PermitEmptyPassword
иUsePAM
оба включены, OpenSSH сервер всегда пытается проверка подлинности с помощью пароля нуля, которое он принимает , как знак того, что аутентификация не требуются для данного аккаунта. Он делает это, как только начинается процесс аутентификации, в обоих протоколах, а не в ответ на любой «реальный» запрос аутентификации от клиента. OpenSSH разрешит такой доступ, только если установлен флаг sshd_configPermitEmptyPassword
; к сожалению, при написании кода он в любом случае выполняет проверку пароля и, таким образом, выдает PAM как сбой.Итак: отключите
PermitEmptyPassword
илиUsePAM
, но помните: без PAM вы не сможете войти без ключа.Ссылка: https://groups.google.com/forum/?fromgroups=#!topic/comp.security.ssh/wExY8lWlG-c
источник
Я думаю, что когда вы входите в систему, Ubuntu выполняет один или несколько из этих файлов:
Вы могли видеть, что в них, и, возможно, даже попытаться выполнить их, чтобы увидеть, что занимает так много времени.
источник
По моему ограниченному опыту, когда работает putty, но Linux, в данном случае Ubuntu, этого не делает, он обычно сохраняется. Проблемы с сетью или сервером могут повлиять на обе клиентские ОС.
Вы можете использовать вышеупомянутый параметр keep alive в командной строке, но набирать его довольно утомительно.
Проще редактировать несколько файлов конфигурации.
Если у вас есть
root access
и вы хотите включить его автоматически для всех пользователей, отредактируйте/etc/ssh/ssh_config
, добавьтеЕсли у вас нет корневого доступа или вы хотите включить его для одного пользователя, отредактируйте
~/.ssh/config
и добавьте те же две строки.источник
Проверьте системные журналы в / var / log, вы можете найти сообщение с соответствующей ошибкой / тайм-аутом.
источник
Если у вас есть время, подождите, прежде чем
редактировать
/etc/sshd_config
и установить (или добавить)
или добавьте свой ip,
/etc/hosts
если он статический локальныйисточник
Возможно, вы захотите попытаться отслеживать запущенные процессы, когда вы входите на сервер с уже подключенного соединения (или другой консоли). Существует возможность определить, какие процессы наиболее активны или используют больше всего процессоров в то время.
Ниже приведен один из возможных методов:
top
туда, чтобы увидеть, что происходит.Обратите внимание, что если задержка не вызвана какими-либо интенсивными процессорами, вы не найдете ничего неуместного. В этом случае проблема может быть связана с вводом / выводом (ожидание чтения / записи диска или сетевой ответ).
источник