web-dev-qa-db-fra.com

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 de resolv.conf semblent ne s'appliquer 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.tld se trouve sur la ligne search dans /etc/resolv.conf et avec Host, le nom est correctement recherché compte tenu de ces règles. Cependant, avec le client SSH ssh je 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 de resolv.conf s'appliquaient au système global.

Remarque: /etc/hosts ne déclare pas le nom pangolin. Le package openssh-server est configuré sur la machine cible. La question est simplement de savoir pourquoi la résolution de noms n'est pas cohérente entre ces deux programmes.

Autre remarque: la commande fonctionne correctement lorsque je saisis le nom de domaine complet, à savoir pangolin.subdomain.domain.tld.

En attendant, 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 /etc/nsswitch.conf complet:

$ 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 de resolv.conf dans 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.

Remarque: la transformation des noms de domaine a été effectuée avec sed, de sorte que les différents fichiers reproduits sont cohérents.


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

$ 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
14
0xC0000022L

Alors que sshet d'autres programmes tels que pingutilisent le résolveur glibc pour rechercher le nom de l'hôte ('pangolin' dans ce cas), Hostrecherche directement le nom dans DNS, en contournant le résolveur glibc. C'est la différence.

Cependant, étant donné que le résolveur glibc est configuré pour essayer dnsaprès filesname__, je ne peux pas expliquer pourquoi le résolveur échoue là où Hostréussit.

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

12
jdthood

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

9
Arnaud Kleinveld

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 trouvé que dans mon nsswitch.conf, il y avait mdns en plus de files et dns. Supprimer mdns4 a résolu ce problème pour moi.

3
J Hart

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

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

3
Louy

Je l'ai rencontré plusieurs fois et cela me renvoie toujours jusqu'à ce que je me souvienne de la restriction de six domaines de la liste de recherche dans resolv.conf.

3
golights