долгая задержка при входе в систему с CentOS7

У меня система CentOS 7, и когда я вхожу в систему с помощью putty или ssh, появляется долгая задержка, прежде чем я получаю запрос пароля. Я запустил ssh -v и обнаружил, что доходит до следующего:

debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received

, затем он остается там 1-2 минуты, а затем выводится такой вывод:

debug1: Authentications that can continue:
publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available
debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available
debug1: Unspecified GSS failure.  Minor code may provide more information
debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available
debug1: Next authentication method: publickey
debug1: Trying private key: /home/motor/.ssh/id_rsa
debug1: Trying private key: /home/motor/.ssh/id_dsa
debug1: Trying private key: /home/motor/.ssh/id_ecdsa
debug1: Trying private key: /home/motor/.ssh/id_ed25519
debug1: Next authentication method: password

И затем появляется запрос пароля. Это происходит независимо от того, какой пользователь входит в систему. Это происходит только в системе 1. У меня есть еще 5, где это происходит без задержки.

В журналах нет диска, памяти или каких-либо других ошибок.

Что может быть причиной такой задержки?

ОБНОВЛЕНИЕ:

I попытался установить для параметра GSSAPIAuthentication значение «Нет», но это не помогло.

Я снова запустил ssh, на этот раз с -vvv. Этот вывод вышел, а затем завис:

debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/motor/.ssh/id_rsa ((nil)),
debug2: key: /home/motor/.ssh/id_dsa ((nil)),
debug2: key: /home/motor/.ssh/id_ecdsa ((nil)),
debug2: key: /home/motor/.ssh/id_ed25519 ((nil)),

Через 1-2 минуты появилось следующее:

debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/motor/.ssh/id_rsa
debug3: no such identity: /home/motor/.ssh/id_rsa: No such file or directory
debug1: Trying private key: /home/motor/.ssh/id_dsa
debug3: no such identity: /home/motor/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /home/motor/.ssh/id_ecdsa
debug3: no such identity: /home/motor/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: /home/motor/.ssh/id_ed25519
debug3: no such identity: /home/motor/.ssh/id_ed25519: No such file or directory
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password

И затем запрос пароля.

12
задан 17 November 2016 в 23:35
2 ответа

В вашем / etc / ssh / sshd_config на удаленном сервере вы следует изменить параметр GSSAPIAuthentication на нет. Перезапустите sshd, и все будет в порядке.

edit: GSSAPI (Generic Security Service Application Programming Interface) - это, по сути, API, который использует библиотеки Kerberos для обеспечения надежного сетевого шифрования. Если нет особой причины, по которой вам нужен GSSAPI, этот метод должен решить вашу проблему.

edit2: Для ясности, также возможно, что обратная проверка DNS имеет тайм-аут (в частности, проверка записи PTR подключающихся хостов). SSH выполняет эту проверку как нечто само собой разумеющееся, потому что он действует как мера безопасности для проверки подключающегося хоста.

Сказав это, процесс не добавляет много с точки зрения реальной безопасности, потому что реально существует значительная часть хостов, которые не все равно есть PTR. Есть три способа решить эту проблему:

1). Вы можете изменить файл sshd_config , чтобы использовать параметр UseDNS no . Это остановит обратный поиск DNS. Это безопасно.

2). Добавьте запись PTR в соответствующую систему DNS для хоста, который медленно подключается.

3). Добавьте вручную запись в файл ОС hosts с соответствующей записью.

Надеюсь, это поможет!

14
ответ дан 2 December 2019 в 21:35

Звучит как проблема с DNS - во время попытки входа выполняется обратный поиск DNS, чтобы указать имя удаленного хоста в журналах аутентификации.

Убедитесь, что сервер не имеет неотвечающего преобразователя в файле /etc/resolv.conf .

3
ответ дан 2 December 2019 в 21:35

Теги

Похожие вопросы