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

44

Подключение к одному из моих серверов с использованием 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
M-Jack
источник
1
Обычно для меня медленные SSH-соединения - это проблемы с DNS, может ли это быть здесь? Например, сервер может застрять, пытаясь сделать обратный DNS для IP-адреса клиента и ждать, пока это
истечет
На самом деле нет: по умолчанию UseDNS не определен в sshd_config, и на странице man сказано, что по умолчанию эта опция «no».
М-Джек,
3
Некоторые пользователи Google считают, что это может быть вызвано обновлением systemd без перезагрузки. И было обновление systemd для xenial 12 июля . systemctl restart systemd-logindисправляет проблему только на короткий промежуток времени для меня.
Иван Козик
Или, если вы видите, pam_systemd(sshd:session): Failed to create session: Connection timed outкак упомянуто в ответе, это может быть github.com/systemd/systemd/issues/2925
Иван Козик
Я пришел сюда с этой проблемой после обновления, и предложение @ IvanKozik устранило проблему - то есть systemctl restart systemd-logind - так что спасибо за это.
Пол М

Ответы:

43

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

Страхиня Кустудич
источник
Я попытался перезапустить systemd-logind, но через некоторое время он говорит, что демон PolicyKit отключен от шины. Мы больше не являемся зарегистрированным агентом аутентификации. Задание для systemd-logind.service не выполнено из-за превышения времени ожидания. Смотрите "systemctl status systemd-logind.service" и "journalctl -xe" для подробностей.
Кун Рен
@KunRen вам, вероятно, нужно перезапустить polkitсервис, используя systemctl restart polkit.
Страхиня Кустудич
16

нашел ответ:

изменил UsePAM с да на нет в файле sshd_config

После перезапуска службы ssh соединение теперь происходит непосредственно с сервером. На этом сервере PAM связан с ldap, поэтому, возможно, это и есть причина, даже если здесь я подключаюсь к пользователю, объявленному на самом сервере, а не к LDAP.

Что ж, это скорее способ обойти проблему, а не решение ... У меня другие серверы настроены так же, как и эта проблема.

Надеюсь, что это может помочь кому-то ...

M-Jack
источник
1
изменение UsePAM на no не имеет других эффектов. Посмотрите это обсуждение. Поэтому мне пришлось установить пароль для пользователя, потому что я получил ошибки, такие как «Пользователь nagios» не разрешен, потому что учетная запись заблокирована
M-Jack
4
Это действительно не очень хорошая идея.
Jakuje
1
Зачем ?? любая альтернатива?
М-Джек
8
PAM используется для других целей управления учетными записями в современных системах. Вместо того, чтобы выключать его, вам лучше разобраться, что происходит в стеке PAM и почему это занимает так много времени.
Jakuje
Оставив очень часто неиспользуемый модуль PAM включенным для доступа SSH, это дыра в безопасности. Ограничение доступа к критически важным службам, таким как SSH, с точки зрения безопасности всегда является хорошей идеей для ЛЮБОГО другого сервиса. Когда вы хотите, чтобы модуль PAM сотрудничал с SSH? Например: когда вам нужно интегрировать его с активным каталогом через winbind, когда вам нужно двухфакторную аутентификацию с токенами Google и т. Д. В других случаях (при использовании passwd и shadow) его отключение совершенно безопасно. Каждый пользователь PAM должен увидеть это: cve.mitre.org/cgi-bin/cvekey.cgi?keyword=pam
Михал Соколовский
10

Это произошло на двух из моих серверов 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файлы журнала; Как только я это сделал, подключение к серверам снова стало мгновенным.

Ричард Ферн
источник
Это решило мою проблему! Спасибо. Хорошо поймал. SSH занимал 5-10 секунд, и теперь это меньше, чем мгновение ока. Это на виртуальной машине, которую я подключал к общедоступному Интернету в течение многих лет. Его правила брандмауэра, вероятно, могли бы быть настроены немного лучше, теперь, когда я об этом думаю. Для других это все, что я сделал: sudo truncate -s 0 /var/log/btmp- У меня был 2,7G в размерах.
Карл Беннетт
2

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

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

RandomControl
источник
То же самое на нашем сервере под управлением CentOS 6.10. Перезапуск rsyslog позаботился об этом. Дело в том, что он не был мертвым. Он работал, но, видимо, ничего полезного не делал.
UtahJarhead
1

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

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

echo "" > /var/log/btmp

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

Марек Надь
источник
3
Это требует гораздо большего объяснения. Для начала, почему вы думаете, что это полезно?
Свен
совет: просто печатать :> /var/log/btmpделает то же самое кстати.
Мариус
1

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

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
tamasgal
источник
Нет, добавление UseDNS no- это решение совершенно другой проблемы.
Касперд
@kasperd Это не имеет значения. В моем случае у меня были те же самые симптомы (кратко: застрял после произнесения «залог: сеть»), и это то, что, наконец, помогло, так что это решение по крайней мере очень похожей проблемы, и я уверен, что это поможет одному или другой в какой-то момент.
Тамасгал
То же самое здесь, два зависания во время соединения, один после sign_and_send_pubkey, более длинный после pledge: network. Добавление только UseDNS noс последующим service ssh restartразрешило проблему на старой установке Ubuntu 14.04.5 LTS здесь.
гончая
0

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

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

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

Ambidex
источник