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.
-
hostqueries DNS, então basicamente ele procura em/etc/resolv.confe 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/hostse outras fontes antes de consultar outros servidores DNS, portanto, sehostconsultar esse servidor local, os resultados de/etc/hostspodem ser inseridos. -
sshsegue seu próprio caminho. Vou descrever o que oopensshfaz 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_confige por usuário~/.ssh/config), depois procura outras origens na ordem especificada pela diretivahosts:em% código%. Diga que é algo como:hosts: files dnsisso significa: procure em
/etc/nsswitch.confe, em seguida, consulte o DNS (/etc/hostsnovamente). Outras origens possíveis são o diretório obsoleto/etc/resolv.confenisservices, 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.