(Doszedłem do wniosku, że jest to związane nscd; proszę zobaczyć na dole pytania)
Próbuję połączyć się z serwerem bezgłowym za pośrednictwem laptopa; współużytkują przewodowe łącze za pośrednictwem routera bezprzewodowego Linksys i przełącznika Ethernet TP-Link. Korzystam z Arch Linux na obu komputerach, używając do konfiguracji sieci całkiem domyślnej konfiguracji Systemd z dhcpcd.
Po ostatniej aktualizacji systemu na laptopie, podczas próby ssh na serwerze (nazywał to „myserver”), wystąpił następujący błąd:
$ 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
Uruchomienie tego samego polecenia z stracepokazuje, że błąd pochodzi z 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)
Jednak ping myserverdziała prawidłowo:
$ 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
Zazwyczaj mam lokalne namedzapytania DNS, ale błąd występuje nadal, gdy wracam do bezpośredniego używania serwera DNS routera:
$ sudo cat /etc/resolv.conf
# Generated by resolvconf
nameserver 192.168.1.1
Błąd występuje sporadycznie: co kilka minut mogę się pomyślnie połączyć. Kiedy mogę się połączyć, widzę, że connectużywa adresu IPv4:
connect(3, {sa_family=AF_INET, sin_port=htons(22), sin_addr=inet_addr("192.168.1.149")}, 16) = 0
Jednak hostpolecenie pokazuje ten sam adres IPv4, niezależnie od tego, czy połączenie działa, czy jest zerwane:
$ host myserver
myserver has address 192.168.1.149
Po przeczytaniu tego pytania pomyślałem o ręcznym określeniu interfejsu ( ssh -v -v -F /dev/null -B en0 myserver). Eliminuje to występujący błąd, ale nie jest to dla mnie trwałe rozwiązanie i nie wyjaśnia, dlaczego błąd nagle się pojawił.
Użyłem whilepętli w mojej powłoce, aby określić czas do najbliższej sekundy, kiedy przejście sshz pracy do pracy nie działa, i odwrotnie, i nie byłem w stanie skorelować tych zdarzeń z niczym na wyjściu journalctl, w tym z dhcpcdkomunikatami.
Pierwotnie opublikowałem to w Inżynierii sieci, gdzie konfiguracja hosta okazuje się być nie na temat. Na tej stronie użytkownik Ricky Beam opublikował częściową odpowiedź:
Cokolwiek robi rozpoznawanie nazw hostów, zwraca lokalne adresy IPv6, które nie są prawidłowe dla wybranego interfejsu - tzn. „Dowolny”. Adresy lokalne dla łącza muszą określać interfejs - np. fe80: ...: 1% eth0
Dlaczego otrzymujesz adres lokalny dla łącza, jest nieznany. Być może osoby zaznajomione z Arch Linux mogą udzielić dalszej pomocy.
Aktualizacja: Wydaje się, że jest to problem z nscd„demonem pamięci podręcznej usługi nazw”, co tłumaczy sporadyczne występowanie problemów (prawdopodobnie związane z wygaśnięciem pamięci podręcznej). Jest to naprawione za pomocą:
sudo systemctl stop nscd.service
Kiedy zatrzymuję ncsd, sshjest w stanie połączyć się przy użyciu lokalnego adresu linku, ale tym razem connectwywołanie określa również mój podstawowy interfejs „en0” i udaje się to:
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
Sądzę, że pozostałe pytanie (które mogę zadać osobno) brzmi: czy jest to błąd w nscd i czy powinienem w ogóle używać nscd?
nscd. A teraz wciąż dostaję adresy lokalne dla lokalnych hostów, ale sshdziała. Zaktualizowałem pytanie ... Wszelkie dalsze spostrzeżenia są mile widziane.