l'hôte est capable de résoudre un nom d'hôte, ssh n'est pas

J'essaie de me connecter d'un système 10.04 à un système 12.04 via SSH. Curieusement, les règles ne resolv.confsemblent prendre effet que de manière sélective, ce qui me laisse perplexe. Observer:

[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.tldest en searchligne /etc/resolv.confet l'utilisation hostdu nom est correctement recherchée compte tenu de ces règles. Cependant, avec le client SSH, sshje reçois l'erreur reproduite ci-dessus. Comment se peut-il? J'ai toujours eu l'impression que les règles de résolution de noms resolv.confs'appliquent au système global.

Remarque: /etc/hostsne déclare pas du pangolintout le nom . Le package openssh-serverest configuré sur la machine cible. La question est uniquement de savoir pourquoi la résolution de noms n'est pas cohérente entre ces deux programmes.

Une autre remarque: la commande fonctionne bien lorsque j'entre le nom de domaine complet, c'est-à-dire pangolin.subdomain.domain.tld.

Pendant ce temps, j'ai redémarré la machine cliente (10.04) et le problème persiste. Un démon de mise en cache DNS n'est pas installé, donc je pense que cela n'aurait pas dû être un problème de toute façon.

Les informations demandées dans le commentaire:

$ grep host /etc/nsswitch.conf
hosts:          files dns

/etc/resolv.conf, J'ai transformé les noms de domaine de manière cohérente:

# 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

... et le plein /etc/nsswitch.conf:

$ 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

... et /etc/network/interfaces, qui est la source du resolv.conf12.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.

Remarque: la transformation des noms de domaine a été effectuée avec sed, il est donc cohérent entre les différents fichiers reproduits.

Il n'y en a pas ~/.ssh/config, mais voici le global ( /etc/ssh/ssh_config), rétréci par souci de concision:

$ grep -v '^#' /etc/ssh/ssh_config |grep -v '^[[:space:]]*$'
Host *
    SendEnv LANG LC_*
    HashKnownHosts yes
    GSSAPIAuthentication yes
    GSSAPIDelegateCredentials no

$ mtr pangolin
Name or service not known: Success

Alors sshque d'autres programmes tels que l' pingutilisation du résolveur glibc pour rechercher le nom d'hôte («pangolin» dans ce cas), hostrecherchent le nom directement dans DNS, contournant le résolveur glibc. Voilà la différence.

Cependant, étant donné que le résolveur glibc est, sur votre machine, configuré pour essayer dnsaprès files, je ne peux pas expliquer pourquoi le résolveur échoue là où il hostréussit.

J'ai déjà vu ce comportement signalé lorsque dnsmasq était utilisé comme serveur de noms de transfert local (https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/998712) mais vous n'utilisez pas un tel serveur de noms local; mais peut-être que le problème là et ici n'était pas dans dnsmasq mais dans le résolveur glibc.

Votre ssh peut essayer de résoudre IP6 et expirer. Si vous n'utilisez pas IP6, essayez de désactiver IP6 en /etc/ssh/ssh_configchangeant AddressFamily de anyà inet.

Je suis tombé sur ce couple de fois, et cela me lance toujours jusqu'à ce que je me souvienne de la restriction de six domaines sur la liste de recherche dans resolv.conf.

j'ai obtenu cette erreur en mettant une ligne d'entrée de domaine avant les 2 lignes du serveur de noms par accident. nslookup a fonctionné. wget a fonctionné. échec de ssh, scp, rsync.

déplacement du domaine vers les serveurs de noms ci-dessous et enregistrement de resolv.conf corrigé. rien d'autre n'était nécessaire pour moi.

Je sais que c'est une question ancienne, mais je vais ajouter ce qui a fonctionné pour moi.

J'ai eu le même problème et j'ai constaté que dans mon nsswitch.conf, il y avait mdnsen plus de fileset dns. La suppression a mdns4résolu ce problème pour moi.

J'avais du mal à accéder à mon serveur sftp. L'utilisateur ftp n'a pas pu se connecter à sftp à partir d'un autre serveur. (Solaris - Openssh). J'ai commenté l'entrée "dns" dans le nsswitch.conf et le problème a été résolu.

Merci Arun Janardhanan (IBS Software Services)