Por que não posso usar ssh em um nome de host local (rótulo único): “ssh: connect to host myserver port 22: Argumento inválido”?

Question

(Eu descobri que isso está relacionado a nscd ; por favor, veja a parte inferior da pergunta)

Estou tentando me conectar a um servidor sem cabeçalho por meio do meu laptop; eles compartilham um link com fio por meio de um roteador sem fio Linksys e um comutador ethernet TP-Link. Estou executando o Arch Linux em ambas as máquinas, usando uma configuração padrão do Systemd com dhcpcd para a configuração de rede.

Após uma atualização recente do sistema no laptop, comecei a experimentar o seguinte erro ao tentar enviar ssh para o servidor (vamos chamá-lo de "meu_servidor"):

$ ssh -v -v -F /dev/null myserver
OpenSSH_7.7p1, OpenSSL 1.1.0h  27 Mar 2018
debug1: Reading configuration data /dev/null
debug2: resolving "myserver" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to myserver [fe80::9cd8:b045:5974:c5cf] port 22.
debug1: connect to address fe80::9cd8:b045:5974:c5cf port 22: Invalid argument
ssh: connect to host myserver port 22: Invalid argument

A execução do mesmo comando com strace mostra que o erro vem de connect :

connect(3, {sa_family=AF_INET6, sin6_port=htons(22), inet_pton(AF_INET6, "fe80::9cd8:b045:5974:c5cf", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28) = -1 EINVAL (Invalid argument)

No entanto, ping myserver funciona bem:

$ ping myserver    
PING myserver(myserver (fe80::9cd8:b045:5974:c5cf)) 56 data bytes
64 bytes from myserver (fe80::9cd8:b045:5974:c5cf%en0): icmp_seq=1 ttl=64 time=0.533 ms
64 bytes from myserver (fe80::9cd8:b045:5974:c5cf%en0): icmp_seq=2 ttl=64 time=0.549 ms

Normalmente, tenho um named encaminhando consultas DNS, mas o erro persiste quando volto a usar o servidor DNS do roteador diretamente:

$ sudo cat /etc/resolv.conf
# Generated by resolvconf
nameserver 192.168.1.1

O erro é intermitente: a cada poucos minutos eu consigo me conectar com sucesso. Quando consigo me conectar com sucesso, vejo que connect está usando um endereço IPv4:

connect(3, {sa_family=AF_INET, sin_port=htons(22), sin_addr=inet_addr("192.168.1.149")}, 16) = 0

No entanto, o comando host mostra o mesmo endereço IPv4, independentemente de a conexão estar funcionando ou estar quebrada:

$ host myserver                   
myserver has address 192.168.1.149

Depois de ler o esta pergunta que pensei em especificar a interface manualmente (%código%). Isso elimina o erro quando ocorre, mas não é uma solução permanente para mim e não explica por que o erro apareceu de repente.

Eu usei um loop ssh -v -v -F /dev/null -B en0 myserver no meu shell para determinar o tempo até o segundo mais próximo quando while passou do trabalho para não funcionar e vice-versa, e não consegui correlacionar esses eventos com nada no saída de ssh , incluindo as mensagens journalctl .

Originalmente, publiquei isso em Engenharia de Rede, onde a configuração do host acaba sendo fora do assunto. Nesse site, o usuário Ricky Beam postou uma resposta parcial:

Whatever is doing hostname resolution is returning link-local IPv6 address(es) that aren't valid for the interface selected -- i.e. "any". Link-local addresses must specify the interface -- eg. fe80:...:1%eth0

Why you're getting a link-local address is unknown. Perhaps people familiar with Arch linux could provide further assistance.

Atualização: parece haver um problema com o dhcpcd "daemon de cache do serviço de nome", o que explica a intermitência que eu estava experimentando (presumivelmente relacionada à expiração do cache). É corrigido com:

sudo systemctl stop nscd.service

Quando eu paro o ncsd, o nscd é capaz de se conectar usando um endereço local de link, mas desta vez a chamada ssh também especifica minha interface primária "en0" e é bem-sucedida:

connect(3, {sa_family=AF_INET6, sin6_port=htons(22), inet_pton(AF_INET6, "fe80::9cd8:b045:5974:c5cf", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=if_nametoindex("en0")}, 28) = 0
write(2, "debug1: Connection established.\r"..., 33) = 33

Eu acho que a questão restante (que eu poderia perguntar separadamente), é, isso é um bug no nscd, e eu deveria estar usando nscd em tudo?

    

Answer 1

Quando eu trouxe um Raspberry Pi para a rede, esse problema manifestou-se de uma maneira nova e finalmente consegui diagnosticá-lo.

O problema está relacionado a systemd-resolved . Isso tem afetado outros usuários, veja por exemplo Ask do Ubuntu procura nslookup ip, mas ping não ou systemd-resolved não consulta servidor dns para local domínio .

Eu supus que ssh myserver acionaria uma pesquisa de DNS de %código%. No entanto, esse não é o caso do meu sistema, aqui está o padrão myserver :

$ cat /etc/nsswitch.conf
# Name Service Switch configuration file.
# See nsswitch.conf(5) for details.
...
hosts: files mymachines myhostname resolve [!UNAVAIL=return] dns
...

O componente nsswitch.conf é resolve , que é um Lennart Poettering projeto para implementar o Zeroconf protocolos DNS multicast e Nome do Link Multicast local Resolução .

O systemd-resolved significa que quando [!UNAVAIL=return] é disponível, a resolução do host DNS nunca é usada. Geralmente isso não é problema porque systemd-resolved também é capaz de criar consultas DNS. No entanto, aparentemente, não faz isso para nomes de host de rótulo único como systemd-resolved , mesmo quando o servidor DNS está no meu roteador local (192.168.1.1). Isto é porque é raciocinado que single-label hostnames não devem ser expostos à rede externa, como explicado por Lennart em este tópico do Github .

Isso explica o fato de que myserver produziu um endereço IPv4 (do roteador), enquanto host myserver produziu um endereço IPv6 (de Multicast DNS ou LLNR, não tenho certeza qual).

Fiquei confuso com isso porque nunca aprendi sobre o DNS Multicast ou LLNR ou IPv6. Eu nunca aprendi sobre essas tecnologias porque eu achava que as tecnologias familiares de IPv4 e DNS eram suficientes para eu.

Aparentemente, ssh myserver é necessário não apenas para produzir Zeroconf solicita, mas também para responder a eles. O Raspberry Pi que eu trouxe para minha rede teve seu systemd-resolved parado para alguma razão, embora eu pudesse procurar o nome do host com systemd-resolved e host , não consegui ver via dig ou ssh :

$ ping raspberrypi
ping: raspberrypi: Name or service not known
[2]$ host raspberrypi
raspberrypi has address 192.168.1.135

Isso me levou ao primeiro relatório de bug Ask Debian acima, que me levou a a solução. Se eu começar ping no Pi então eu sou capaz para systemd-resolved e ping it. No entanto, se eu desativar ssh localmente, também posso systemd-resolved e ping para o Pi.

Por enquanto, acabei de desativar ssh em todos os meus sistemas

$ sudo systemctl stop systemd-resolved.service
$ sudo systemctl disable systemd-resolved.service

pois parece criar problemas com systemd-resolved do GNU libc e como requer que eu aprenda sobre tecnologias como IPv6, mDNS e LLNR, que eu não preciso atualmente - porque meus computadores estão todos conectados para um roteador consumidor básico que fornece tecnologias familiares de DNS e NAT fora da caixa.

Obrigado a todos que comentaram a minha pergunta original, mas no final não era necessário "configurar um prefixo ULA ou obter conectividade global IPv6, ou ambos "via" uma configuração em seu roteador doméstico, se não é um pedaço completo de "ou" para gritar com o seu ISP ". Eu só teve que desativar alguns dos novos softwares de Lennart para me afastar a borda do sangramento. O tópico do Github tem alguma discussão sobre se o software está realmente se comportando corretamente, mas eu me encontro no mesma posição que muitos outros usuários: depois de passar horas de tempo Descobrir que nscd é o culpado, prefiro não passar mais horas tentando entender como corrigi-lo, quando a desativação é tão fácil.