Почему запрос пароля вводится навсегда, когда я захожу по SSH на сервер Ubuntu 9.05?

Question

Ответ: На самом деле он выполнял обратное DNS-разрешение. Основываясь на предложениях, приведенных ниже, и этой статье, я добавил "UseDNS no" в свой sshd_config, перезагрузил ssh, и теперь сразу появляется запрос пароля.

Когда я захожу по SSH на свой сервер, мне выдается стандартное приглашение «login as:», а затем приглашение «user @ host's password:». По какой-то причине второй показ всегда занимает некоторое время. Мой сервер не загружен и обычно выполняет команды довольно быстро.

Теперь мы говорим всего 10 секунд или около того между тем, как я нажимаю Enter для имени пользователя, и когда появляется второе приглашение, но когда вы делаете это много, это раздражает. Я подозреваю, что Ubuntu ищет мою учетную запись пользователя, но у нее <5 учетных записей на всю установку.

Обновление @Josh /var/log/messages содержит этот гем:

Oct 28 16:54:59 Athena sudo: pam_sm_authenticate: Called
Oct 28 16:54:59 Athena sudo: pam_sm_authenticate: username = [msmith]
Oct 28 16:54:59 Athena sudo: Warning: Using default salt value (undefined in ~/.ecryptfsrc)
Oct 28 16:55:01 Athena sudo: Passphrase key already in keyring; rc = [1]
Oct 28 16:55:02 Athena sudo: Passphrase key already in keyring; rc = [1]
Oct 28 16:55:02 Athena sudo: There is already a key in the user session keyring for the given passphrase.

Где msmith - мое имя пользователя. Что все это значит?

Answer 1

Возможно ли, что это делает обратный поиск DNS на вашем IP? Вы можете проверить результаты онлайн, если клиент использует публичный IP-адрес, или использовать что-то вроде следующего с вашего сервера:

dig -x CLIENT_IP_ADDRESS

Есть ли что-нибудь в /var/log/messages?

Answer 2

Вероятно, обратное разрешение DNS (сервер пытается получить имя клиента по IP-адресу) требует времени. Можете ли вы проверить, есть ли в /etc /ssh /sshd_config параметр "VerifyReverseMapping yes"? Установите для него "VerifyReverseMapping no" и проверьте, помогает ли.

Редактировать: Кажется, что VerifyReverseMapping устарела, и useDNS - это новая конфигурация в sshd_config.

Answer 3

В вашем файле sshd_config установите GSSAPIAuthentication = нет

https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/84899

Answer 4

Вы всегда можете войти в систему с именем пользователя, чтобы начать с:

ssh user@server

это имеет какое-либо влияние?

Если вы используете PuTTY, его можно настроить в разделе Соединение -> Данные в качестве имени пользователя для автоматического входа.

Answer 5

Если у вас нет подходящих доменных имен для всего, просто создайте что-нибудь и поместите это в /etc/hosts . Посмотрите, пойдет ли это быстрее ... не беспокойтесь о .com просто используйте "Боб, Кэрол, Тед, Алиса" или все, что вы хотите ...

Если проблема заключается в тайм-аутах решателя, тогда это будет исправлено.

Answer 6

Я нашел альтернативное решение этой проблемы:- http://www.patrickmin.com/linux/tip.php?name=ssh_pause

У меня возникла такая же проблема при входе в систему сборки Linux с помощью Putty под Windows. Добавление IP-адреса моего окна Windows в /etc /hosts на машине linux решило проблему.

Answer 7

Просто для записи, я столкнулся с той же проблемой, когда ssh быстро шел из дома на мой домашний сервер (в основном используя его для git), но на работе потребовалось бы 10-20 секунд, чтобы получить запрос пароля.

Мне пришлось отключить UseDNS no и перезапустить sshd sudo systemctl restart sshd.service . Тогда это работает из всех мест.

Я знаю, что на вопрос дан ответ и он принят, но я хотел добавить информацию, так как мне пришлось "активно" установить ее на « нет» , чтобы заставить ее перестать использовать dns.

Answer 8

Помните, что клиент также выполнит проверку обратного DNS, что может занять до 30 секунд или более, если сопоставление обратного DNS не существует с определенными конфигурациями разрешения.

В /etc/ssh/ssh_config или в ~/.ssh/config установите CheckHostIP no чтобы отключить этот поиск на стороне клиента.

Смотрите man 5 ssh_config для более подробной информации.

Answer 9

Пожалуйста, проверьте, работает ли nslcd (демон LDAP):

ps -ef | grep nslcd

Это может вызвать эту проблему.

Если он работает, остановите его и удалите из списка служб

service nslcd stop
chkconfig nslcd off