ssh зависает в течение ~ 15 секунд перед подключением
Если я напрямую подключаюсь к серверу A, используя открытый ключ auth с моего компьютера, он принимает & lt; 0,5 с. Но если запустить ту же команду ssh с сервера B (для подключения к серверу A), она замерзает около 15 секунд в следующей строке: ( complete log )
debug2: ssh_connect: needpriv 0
Поскольку Я могу ssh нормально, я предполагаю, что это проблема конфигурации на сервере B.
Кроме того, я пробовал sshing от B до A, используя другую учетную запись (с паролем auth). Он тоже висит на одной линии для той же суммы. Это заставляет меня думать, что это проблема с конфигурацией системы ssh, поэтому я отправляю свой /etc/ssh/ssh_config .
Я запускал разницу в моем ssh_config и сервере B. Результат не дал никаких различий.
Оба сервера A и B запускают Lucid.
4 ответа
Может быть проблемой DNS. Вы все еще получаете задержку, если используете IP-адрес вместо имени хоста?
-
1что такое проблема DNS? Поиск DNS работает сразу с другими инструментами (например, ping). я бы скорее решил проблему DNS, чем использовать IP-адрес все время. – Jayen 23 April 2015 в 07:20
-
2Не все инструменты используют одни и те же поисковые запросы. Если все хорошо, и вы только просматриваете хосты в файлах и DNS, они проходят через /etc/nsswitch.conf, затем /etc/host.conf, затем / etc / hosts, а затем, если они не найдены, DNS. На моем Ubuntu 14.04, ping и ssh оба делают это. Убедитесь, что вы тестируете одно и то же имя хоста. Кроме того, проверьте, не определены ли ваши ~ / .ssh / config какие-либо псевдонимы, которые влияют на ваш тест. – Reinier Post 25 November 2016 в 16:52
Может быть проблемой DNS. Вы все еще получаете задержку, если вместо имени хоста используете IP-адрес?
Вероятнее всего, причиной может быть DNS.
Чтобы убедиться, что это связано с разрешением DNS, попробуйте отключить проверку DNS, поставив следующее на /etc/ssh/sshd_config на вашем сервере:
UseDNS No
-
1
-
2@Jayen На самом деле это не нужно DNS. Но по умолчанию он будет выполнять обратный DNS на IP-адрес клиента, за которым следует переадресация DNS в результирующем имени хоста, а если результаты не совпадают, он будет записывать POSSIBLE BREAK-IN ATTEMPT в журнал. И эти логические операторы сбивают с толку и вряд ли когда-либо полезны, поэтому я помещаю UseDNS No в конфигурацию на каждом сервере, который я администрирую. – kasperd 25 November 2016 в 11:18
-
3в то время как это имеет смысл, что не соответствует принятому ответу, указывающему на проблему DNS на клиенте. – Jayen 25 November 2016 в 12:58
-
4@Jayen Описание симптомов недостаточно детально, чтобы определить, есть ли проблема на стороне клиента или сервера. Раньше я видел проблемы, согласующиеся с симптомами, описанными в вопросе, где основная причина оказалась проблемой DNS на стороне сервера, и указать UseDNS No поможет. Таким образом, этот ответ является хорошим советом, даже если он окажется, что это не причина в конкретном сценарии. – kasperd 26 November 2016 в 00:09
Вероятнее всего, причиной может быть DNS.
Чтобы убедиться, что это связано с разрешением DNS, попробуйте отключить проверку DNS, поместив следующее на /etc/ssh/sshd_config на вашем сервере:
UseDNS No