длительная задержка при входе в систему с 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 других, где это происходит без задержки.

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

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

ОБНОВИТЬ:

Я попытался установить 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

И тогда запрос пароля.

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

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

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

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

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

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

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

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

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

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