SSH к CNAME'у для скрытой службы
TLDR: я могу использовать SSH по луковому адресу, но не по имени хоста, к которому привязан CNAME.
У меня SSH-сервер работает как служба Tor, но я не хочу запоминать адрес лука. Я знаю, что мог бы просто добавить имя в конфигурацию своего клиента SSH, но цель этого - получить доступ к моему компьютеру, когда я одалживаю чужой, и, очевидно, я не хочу слишком много возиться с настройками других людей. , (И да, на этих других компьютерах, скорее всего, уже установлен Tor.) Поэтому я настроил имя хоста с записью CNAME, указывающей на луковый адрес. Если я сделаю torify ssh myaddress.onion, он будет работать нормально, но torify ssh mydomain.com приведет к:
1565911820 ERROR torsocks[31652]: Unable to resolve. Status reply: 4 (in socks5_recv_resolve_reply() at socks5.c:683)
ssh: Could not resolve hostname mydomain.com: Non-recoverable failure in name resolution
(И нет, я не набрал буквально mydomain.com; ошибка отредактирована.)
Выполнение dig -t CNAME mydomain.com возвращает адрес лука. До сих пор все мои тесты проводились на самой хост-машине (LUbuntu 18.04.3).
2 ответа
Это - отказ в Вашем понимании, как DNS работает, объединенный с фактом это .onion не допустимый TLD в общедоступном DNS. Позвольте мне дать Вам интенсивный курс в разрешении CNAME, а также решение для Вас попытаться 'исказить' это на Вашей стороне вещей.
DNS разрешение CNAME
DNS записи CNAME называют псевдонимами. Они действуют как указатель, говоря, что "Этот домен является псевдонимом для этого другого домена, разрешите, что домен и переходит к тому месту назначения".
Если у меня есть домен example1.com с запись 1.2.3.4, который является моим фактическим сервером, и example2.com набор как CNAME example1.com, затем, когда я перехожу в example2.com DNS будет видеть, что DNS записывает для example2.com поскольку рекордное разрешение зависит от записи example1.com. Это работает в НОРМАЛЬНОМ DNS, потому что он публично обратился и способный искаться.
Место назначения CNAME действительно "не совместно используется" как результат поиска DNS для поиска DNS, который делается, только о получающейся записи A/AAAA заботятся и так как не может быть один для .onion это перестало работать к DNS правильно и сбоям. Объяснение ниже.
Почему ЛУКОВОЕ разрешение перестало работать
Записи CNAME НЕ являются тем же как ЛУКОВЫМИ адресами Скалистой вершины. Когда Вы ищете запись CNAME против a .onion адрес в стандартном DNS, это твердые сбои. Это вызвано тем, что в общедоступном DNS, .onion не адресуемо и не допустимый TLD.
Записи CNAME также не 'решают' к адресу псевдонима в формате 'перенаправления' как Вы, думают - CNAME только правильно решит, может ли место назначения указателя CNAME на самом деле возвратить общедоступную запись DNS. Поскольку это - a .onion это никогда не будет так он или NXDOMAINs или SERVFAILs на поисках.
Поэтому Вы получаете ошибку, которую Вы получаете.
Как я могу заставить это работать затем?
Путем 'обмана' и конфигурирования SSH конфигурируются немного.
Попытайтесь добавить этот раздел к Вашему ~/.ssh/config файл (создают файл, если он не существует):
Host mydomain.com
Hostname myaddress.onion
Затем попробуйте к SSH снова к mydomain.com. Это должно повторно указать на это на Ваш .onion адрес негласно.
Однако НЕ полагайтесь на DNS для указания на домены на .onion адреса - они не работают в общедоступном DNS на домены.
plain dns no .. как насчет сохранения в txt-записи и переноса вызова как
torify ssh $(dig +short example.com -t txt)