велика затримка під час входу в CentOS7


15

У мене є система CentOS 7, і коли я входжу в систему за допомогою шпаклівки або 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

І тоді запит на пароль.

Відповіді:


16

У своєму /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файлу ОС із відповідним записом.

Сподіваюся, що це допомагає!


1
Це не вирішило проблеми. Затримка ще є. Я оновлю своє початкове повідомлення з більшою інформацією.
Ларрі Мартелл

6
Це може бути зворотний пошук DNS, який займає свій час; ви можете спробувати додати UseDNS noу файл sshd_config і перезавантажити службу, щоб побачити, чи це має значення.
Бретт Левене

Я не зможу спробувати це до наступного тижня. Я дам вам знати, як це йде. Дякую.
Ларрі Мартелл

2
Так, це було питання. За допомогою UseDNS noвиправленого і усунув затримку. Дякую.
Ларрі Мартелл

4

Це звучить як проблема DNS - під час спроби входу виконується зворотний пошук DNS для надання віддаленого імені хоста в журналах auth.

Переконайтеся, що на сервері немає /etc/resolv.confфайлу, що не відповідає, у файлі.


Так, це було питання. Виправлення цього усунуло затримку. Дякую!
Ларрі Мартелл

Ларрі, я радий, що це вирішило питання. Ви не проти обрати це як прийняту відповідь? Дякую та удачі у ваших майбутніх починаннях.
Адміністратор

Я вибрав відповідь, яку дав Бретт Левене, коли він відповідав перед вами.
Ларрі Мартелл
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.