Подключение к одному из моих серверов с использованием ssh занимает более 20 секунд.
Это не связано с условиями LAN или WAN, поскольку соединение с самим собой требует того же (ssh localhost). После того, как соединение окончательно установлено, взаимодействие с сервером происходит очень быстро.
Использование -vvv показывает, что соединение зависает после того, как вы произнесете "pledge: network". На этом этапе аутентификация (здесь с использованием ключа) уже выполнена, как показано здесь:
...
debug1: Authentication succeeded (publickey).
Authenticated to myserver.mydomain.com ([xx.xx.xx.xx]:22).
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
(... застрял здесь на 15-25 секунд ...)
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug2: callback start
debug2: fd 3 setting TCP_NODELAY
debug2: client_session2_setup: id 0
...
Сервер - Ubuntu 16.04. Это уже случалось со мной в прошлом с другим сервером (был Ubuntu 12.04), nerver нашел решение, и проблема исчезла через некоторое время ...
sshd_config - это файл по умолчанию, предоставляемый Ubuntu.
Пока я пробовал:
Вероятно, это проблема с D-Bus и systemd. Если dbus служба перезапущена по какой-то причине, вам также нужно будет перезапустить systemd-logind.
Вы можете проверить, действительно ли это проблема, открыв журнал демона ssh (в Ubuntu он должен быть /var/log/auth.log) и проверьте, есть ли в нем эти строки:
sshd[2721]: pam_systemd(sshd:session): Failed to create session: Connection timed out
Если да, просто перезапустите systemd-logind служба:
systemctl restart systemd-logind
У меня была такая же проблема с CentOS 7, потому что messagebus был перезапущен (вот как D-Bus сервис называется на CentOS).
нашел ответ:
изменил UsePAM с да на нет в файле sshd_config
После перезапуска службы ssh соединение с сервером устанавливается немедленно. На этом сервере PAM связан с ldap, поэтому, вероятно, это причина, даже если здесь я подключаюсь к пользователю, объявленному на самом сервере, а не к LDAP.
Что ж, это скорее способ обойти проблему, а не решение ... У меня есть другие серверы, настроенные таким же образом, которые не имеют этой проблемы.
Надеюсь, это может кому-то помочь ...
Это произошло на двух моих серверах Fedora 25 из-за множества неудачных попыток входа в систему по SSH.
(Общие предложения по использованию GSSAPIAuthentication=no и UseDNS=no, или перезапуск systemd-logind, не имело никакого значения.)
На этих серверах /etc/pam.d/postlogin содержит:
session optional pam_lastlog.so silent noupdate showfailed
Страница руководства для pam_lastlog объясняет, что showfailed вариант будет:
Отображение количества неудачных попыток входа в систему и даты последней неудачной попытки из btmp.
На этих серверах /var/log/btmp файлы были огромными из-за множества неудачных попыток входа в систему. В btmp файлы журналов тоже не вращались.
Я установил logrotate package, чтобы файлы журналов в будущем менялись. (В Fedora конфигурация, поставляемая с logrotate обрабатывает вращение /var/log/btmp.)
Я также удалил огромное btmp лог-файлы; как только я это сделал, подключение к серверам снова стало мгновенным.
Для меня эта проблема вызвана большим (сотни МБ) btmp файл. Этот файл регистрирует попытки входа в систему. Когда люди пытаются подобрать ваш пароль, этот файл может быть большим и вызывать задержки в "pledge: network" фаза.
Попробуйте очистить файл журнала
echo "" > /var/log/btmp
и посмотрите, поможет ли это.
На Ubuntu 16+ я каждый раз видел ssh -v XXX@YYY торможение в pledge: network это можно исправить, следуя инструкциям, которые я нашел здесь Подробное руководство по исправлению медленных входов в систему по SSH. В частности, задержку вызывает дополнительный модуль PAM, который, по всей видимости, не нужен.
В /etc/pam.d/common-session на машине, на которой вы видите медленный вход (например, сервер). Закомментируйте строку session optional pam_systemd.so. Это должно немедленно решить проблему.
Это позволяет избежать полного выключения PAM, что приводит к повреждению входа в систему с паролями.
В моем случае причиной был сбой rsyslogd. Я узнал об этом, потому что больше не было сообщений журнала, например. / var / log / syslog или /var/log/mail.log
Так service rsyslog restart решил проблему для нас.
Для меня первая подсказка была предоставлена
UseDNS no
к /etc/ssh/sshd_config а потом конечно service ssh restart (на нашем сервере Debian / Jessie).
перед:
ssh git@git.*****.de true 0.03s user 0.01s system 0% cpu 13.440 total
ssh git@git.*****.de true 0.03s user 0.01s system 0% cpu 20.990 total
ssh git@git.*****.de true 0.03s user 0.02s system 0% cpu 31.114 total
ssh git@git.*****.de true 0.03s user 0.01s system 0% cpu 25.898 total
после:
ssh git@git.*****.de true 0.03s user 0.02s system 5% cpu 0.832 total
ssh git@git.*****.de true 0.03s user 0.01s system 7% cpu 0.523 total
ssh git@git.*****.de true 0.03s user 0.01s system 7% cpu 0.574 total
Это показало, что моя конфигурация DNS была неправильной (у меня была опечатка в адресе DNS). После фиксации IP и восстановления настройки UseDNS yes все работало нормально.
Я заметил следующую строку в своем отзыве об отладке:
Control socket connect(/var/lib/jenkins/.ssh/USER@HOST:22): Permission denied
Этот файл принадлежал root:root пока я jenkins. Удаление этого файла решило мои проблемы.
Проблема для меня (Ubuntu 19.10) заключалась в том, что мои:
/etc/pam.d/sshd
# Print the message of the day upon successful login.
# This includes a dynamically generated part from /run/motd.dynamic
# and a static (admin-editable) part from /etc/motd.
session optional pam_motd.so motd=/run/motd.dynamic
session optional pam_motd.so noupdate
Комментируя настройки motd, я сразу понял.
В моем случае это связано с тем, что журналов слишком много. Вы можете проверить, в порядке ли вы, выполнив эту команду:
sudo journalctl --list-boots
Если требуется время, чтобы дать результаты и дать много строк результата, тогда вы в деле.
Чтобы обрезать журналы, сделайте следующее:
sudo journalctl --vacuum-time 2d
Он удалит журналы старше двух дней.