ssh
e host
resolvem nomes seguindo caminhos completamente diferentes, portanto, não é surpreendente que eles gerem resultados diferentes às vezes, especialmente quando o nome a ser resolvido não é um FQDN (daí a sugestão de usar FQDNs em todos os lugares). / p>
Você não menciona nada sobre seu sistema operacional e sua configuração de sistema, então tenho que mantê-lo geral, com um olho no Linux: os detalhes do MacOS são um pouco diferentes, e o Windows ainda mais, mas os conceitos gerais são os mesmos.
-
host
queries DNS, então basicamente ele procura em/etc/resolv.conf
e consulta os servidores listados, possivelmente anexando um nome de domínio se o nome do host ainda não estiver completo. Ele ignora todas as outras fontes possíveis, mas cuidado com o fato de que muitos sistemas executam um servidor DNS de cache local (geralmentednsmasq
) que lê/etc/hosts
e outras fontes antes de consultar outros servidores DNS, portanto, sehost
consultar esse servidor local, os resultados de/etc/hosts
podem ser inseridos. -
ssh
segue seu próprio caminho. Vou descrever o que oopenssh
faz no Linux, outras implementações diferem. Primeiro, ele procura apelidos do host definidos em arquivos de configuração (em todo o sistema/etc/ssh/ssh_config
e por usuário~/.ssh/config
), depois procura outras origens na ordem especificada pela diretivahosts:
em% código%. Diga que é algo como:hosts: files dns
isso significa: procure em
/etc/nsswitch.conf
e, em seguida, consulte o DNS (/etc/hosts
novamente). Outras origens possíveis são o diretório obsoleto/etc/resolv.conf
enis
services, LDAP, ativo, você nomeia-os.
Para depurar seu caso particular, você deve seguir o caminho que a implementação de netinfo
segue e descobrir onde ele fica preso.