В чем смысл опции sshd «UseDNS»?

Я знаю, что он делает, но я не знаю, почему . Какие атаки (а) это предотвращает?

Является ли он релевантным для всех видов методов проверки подлинности? (hostbased, password, publickey, клавиатура-интерактивная …)

  • Удаленная SSH-команда выходит из строя только в сценарии оболочки с ошибкой: «Нет такого файла или каталога»
  • Проблема с pam_mount и sshfs
  • Вход ssh в скрипт Bash
  • Шифрование и расшифровка секретного ключа ssh 3des
  • Как обновить контейнер Fedora OpenVZ через SSH?
  • SSH Ошибка при использовании sshpass
  • sshfs - конечная точка транспорта не подключена
  • Как сценарировать миграцию базы данных с помощью SSH?
  • 5 Solutions collect form web for “В чем смысл опции sshd «UseDNS»?”

    Опция UseDNS в основном бесполезна. Если клиентские компьютеры находятся в Интернете, есть большая вероятность, что у них нет обратного DNS, их обратный DNS не разрешает переадресацию, или их DNS не предоставляет никакой информации, кроме «принадлежит этому ISP ", о котором уже говорит IP-адрес.

    В типичных конфигурациях DNS используется только для ведения журнала. Он может использоваться для аутентификации, но только если IgnoreRhosts no указан в sshd_config . Это касается совместимости со старыми установками, в которых используется rsh, где вы можете сказать: «пользователь, называемый bob на машине, называемый darkstar может войти в систему как alice без каких-либо учетных данных» (написав darkstar bob в ~alice/.rhosts ). Это безопасно только в том случае, если вы доверяете всем машинам, которые могут подключаться к серверу ssh. Другими словами, это очень редко можно использовать безопасным способом.

    Учитывая, что поиск DNS не предоставляет никакой полезной информации, кроме как в особых обстоятельствах, ее следует отключить. Насколько я могу судить, единственная причина, по которой это по умолчанию, заключается в том, что она технически более безопасна (если вас беспокоит аутентификация, а не доступность), хотя это относится только к крошечному набору обстоятельств.

    Другим аргументом в пользу отключения этой функции является то, что каждая лишняя функция представляет собой ненужный риск для безопасности .

    Я добавил в отчет об ошибке (старый, но все еще текущий) в Ubuntu об этом.

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

    Я предложил изменить значение по умолчанию на Нет и добавить к нему новую документацию:

     # UseDNS - Determines whether IP Address to Hostname lookup and comparison is performed # Default value is No which avoids login delays when the remote client's DNS cannot be resolved # Value of No implies that the usage of "from=" in authorized_keys will not support DNS host names but only IP addresses. # Value of Yes supports host names in "from=" for authorized_keys. Additionally if the remote client's IP address does not match the resolved DNS host name (or could not be reverse lookup resolved) then a warning is logged. 

    Это необходимо, когда вы используете параметр FROM в файле authorized_keys и хотите фильтровать по именам, а не только по IP-адресам.

    Параметр FROM в строке файла authorized_keys позволяет ограничить узлы, которые могут использовать определенный ключ.
    Это увеличивает возможность управления несколькими серверами, которые имеют доступ друг к другу, не позволяя клонам машины выдавать себя за свое происхождение, обычно непреднамеренно (оставшиеся crontabs, человеческие ошибки).

    Из man-страницы sshd_config(5) :

      UseDNS Specifies whether sshd(8) should look up the remote host name and check that the resolved host name for the remote IP address maps back to the very same IP address. The default is “yes”. 

    Включение этого делает доступ из местоположения без надлежащего (прямого и обратного) DNS генерирует предупреждение в журналах.

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

    Редактировать: обновлено в соответствии с комментарием Андрея Войтенкова .

    Я хотел бы добавить, что в CentOS 7 (7.1.1503) и, следовательно, в Red Hat Enterprise Linux 7 мне не удалось войти в систему с настройкой yes для UseDNS по UseDNS . После расторжения и установки его no , я смог войти в систему. Таким образом, кажется, что действительно может быть отказано в обслуживании, если DNS работает некорректно! В CentOS 6 кажется, что по умолчанию no и, следовательно, я могу использовать ssh без DNS!

    Я хотел бы добавить, что мои эксперименты проводились на контейнерах LXC, а не на физической машине, в случае, если это имеет значение!

    Linux и Unix - лучшая ОС в мире.