ssh-зв’язок займає назавжди, щоб започаткувати, застрягши в "заставі: мережа"

Для підключення до одного з моїх серверів за допомогою ssh потрібно більше 20 секунд.

Це не пов’язано з умовами локальної мережі або 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), нервер знайшов рішення, і проблема через деякий час відмінилася ...

sshd_config - типовий, який надає Ubuntu.

Поки я намагався:

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

Це, мабуть, проблема з D-Busі systemd. Якщо dbusпослуга з якоїсь причини перезапущена, вам також знадобиться перезапустити systemd-logind.

Ви можете перевірити, чи це проблема, відкривши журнал ssh daemon (на 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. Видалення цього файлу вирішило мої проблеми.