ssh соединение требует вечности для инициации, застрял на «залог: сеть»

Подключение к одному из моих серверов с использованием ssh требует более 20 секунд для инициации.

Это не относится к условиям LAN или WAN, так как соединение с самим собой происходит одинаково (ssh localhost). После того, как соединение наконец установлено, это очень быстро взаимодействует с сервером.

Использование -vvv показывает, что соединение застряло после произнесения «залог: сеть». На этом этапе аутентификация (здесь с использованием ключа) уже выполнена, как видно здесь:

...
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.

Пока что я попробовал:

• используя -o GSSAPIAuthentication = no в команде ssh
• используя пароль вместо ключа
• использование UsePrivilegeSeparation no вместо yes в sshd_config

Это, вероятно, проблема с 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

Страница man для pam_lastlogобъясняет, что showfailedопция будет:

Показать количество неудачных попыток входа в систему и дату последней неудачной попытки от btmp.

На этих серверах /var/log/btmpфайлы были огромными из-за многих неудачных попыток входа в систему. В btmpлог - файлы не были повернуты либо.

Я установил logrotateпакет, чтобы гарантировать, что файлы журнала будут вращаться в будущем. (На Fedora конфигурация, которая поставляется с, logrotateобрабатывает вращение /var/log/btmp.)

Я также удалил огромные btmpфайлы журнала; Как только я это сделал, подключение к серверам снова стало мгновенным.

В моем случае причиной был сбой rsyslogd. Я узнал об этом, потому что больше не было сообщений журнала, например, в / var / log / syslog или /var/log/mail.log

Так что service rsyslog restartрешили проблему для нас.

Для меня эта проблема вызвана большим (сотни МБ) btmpфайлом. Этот файл регистрирует попытки входа в систему. Когда люди пытаются взломать ваш пароль, этот файл может иметь большой размер и вызывать задержки на "pledge: network"этапе.

Попробуйте очистить файл журнала

echo "" > /var/log/btmp

и посмотрим, поможет ли это.

Для меня решение было добавить

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

Я заметил следующую строку в моем отладочном отзыве:

Control socket connect(/var/lib/jenkins/.ssh/USER@HOST:22): Permission denied

Который был файлом, которым владел root:rootпока я jenkins. Удаление этого файла решило мои проблемы.