Я пытаюсь подключиться из системы 10.04 к системе 12.04 через SSH. Как ни странно, правила в resolv.conf
, кажется, вступают в силу только выборочно, что оставляет меня озадаченным. Заметьте:
[2] user@mach:~$ ssh pangolin
ssh: Could not resolve hostname pangolin: Name or service not known
[2] user@mach:~$ host pangolin
pangolin.subdomain.domain.tld has address 172.16.7.12
subdomain.domain.tld
находится в строке search
в /etc/resolv.conf
и, используя host
, имя правильно ищется с учетом этих правил. Однако с клиентом SSH ssh
я получаю ошибку, воспроизведенную выше. Как это может быть? У меня всегда было впечатление, что правила разрешения имен в resolv.conf
применяются системно-глобально.
Примечание: /etc/hosts
вообще не объявляет имя pangolin
. Пакет openssh-server
настроен на целевой машине. Вопрос только в том, почему разрешение имен не согласовано между этими двумя программами.
Еще одно примечание: команда отлично работает, когда я ввожу полное доменное имя, то есть pangolin.subdomain.domain.tld
.
Тем временем я перезагрузил клиентский компьютер (10.04), и проблема все еще существует. Демон кэширования DNS не установлен, поэтому я считаю, что в любом случае это не должно было быть проблемой.
Информация, запрошенная в комментарии:
$ grep host /etc/nsswitch.conf
hosts: files dns
/etc/resolv.conf
, я преобразовал доменные имена последовательно:
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 172.16.1.1
nameserver 172.16.1.5
search subdomain.domain1.com domain1.com domain2 domain3.com domain2.ccTLD domain3.net dev.domain1.com sdk.dev.domain1.com
... и полное [ 1119]:
$ cat /etc/nsswitch.conf
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.
passwd: compat
group: compat
shadow: compat
hosts: files dns
networks: files
protocols: db files
services: db files
ethers: db files
rpc: db files
netgroup: nis
... и /etc/network/interfaces
, который является источником для resolv.conf
в 12.04:
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet static
address 172.16.1.234
netmask 255.255.0.0
gateway 172.16.255.254
dns-nameservers 172.16.1.1 172.16.1.5
dns-search domain1.com. domain2. domain3.com. domain2.ccTLD. domain3.net. dev.domain1.com. sdk.dev.domain1.com. subdomain.domain1.com.
dns-domain subdomain.domain1.com.
Примечание: преобразование доменных имен было выполнено с sed
, так что это согласуется между различными воспроизводимыми файлами.
Нет ~/.ssh/config
, но вот глобальный (/etc/ssh/ssh_config
), сокращенный ради краткости:
$ grep -v '^#' /etc/ssh/ssh_config |grep -v '^[[:space:]]*
$ mtr pangolin
Name or service not known: Success
Host *
SendEnv LANG LC_*
HashKnownHosts yes
GSSAPIAuthentication yes
GSSAPIDelegateCredentials no
$ mtr pangolin
Name or service not known: Success
В то время как ssh
и другие программы, такие как ping
, используют преобразователь glibc для поиска имени хоста (в данном случае «pangolin»), host
ищет имя непосредственно в DNS, минуя распознаватель glibc. В этом разница.
Однако, учитывая, что на вашей машине сконфигурирован решатель glibc для попытки dns
после files
, я не могу объяснить, почему происходит сбой распознавателя в случае успеха host
.
Я видел такое поведение ранее, когда dnsmasq использовался в качестве локального сервера пересылки имен (https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/998712), но вы не используете такой локальный сервер имен; но, возможно, проблема там и здесь была не в dnsmasq, а в glibc resolver.
Я сталкивался с этим пару раз, и это всегда бросало меня, пока я не запомнил ограничение шести доменов в списке поиска в resolv.conf.
Я знаю, что это древний вопрос, но я добавлю, что сработало для меня.
У меня была та же проблема, и я обнаружил, что в моем nsswitch.conf
было mdns
в дополнение к files
и dns
. Удаление mdns4
решило эту проблему для меня.
Я получил эту ошибку, поставив строку входа в домен перед двумя строками сервера имен случайно. nslookup работал. Wget работал. ssh, scp, rsync не удалось.
Исправлено перемещение домена на серверы имен ниже и сохранение resolv.conf. мне больше ничего не нужно было.
Ваш ssh может попытаться разрешить IP6 и сделать это по истечении времени ожидания. Если вы не используете IP6, попробуйте отключить IP6 в /etc/ssh/ssh_config
, изменив AddressFamily со any
на inet
.
Я столкнулся с проблемой доступа к моему серверу sftp. Пользователь ftp не смог войти в sftp с другого сервера. (Солярис - Опенссш). Я прокомментировал запись «dns» в nsswitch.conf, и проблема была решена.
Спасибо Арун Джанардханан (IBS Software Services)