Warum kann ich nicht auf einen lokalen (Single-Label-) Hostnamen ssh: "ssh: Verbindung zum Host-Myserver-Port 22 herstellen: Ungültiges Argument"?

(Ich habe herausgefunden, dass dies im Zusammenhang mit steht nscd. Bitte lesen Sie den unteren Teil der Frage.)

Ich versuche, über meinen Laptop eine Verbindung zu einem kopflosen Server herzustellen. Sie teilen sich eine kabelgebundene Verbindung über einen Linksys-WLAN-Router und einen TP-Link-Ethernet-Switch. Ich verwende Arch Linux auf beiden Rechnern und verwende ein ziemlich standardmäßiges Systemd-Setup mit dhcpcd für die Netzwerkkonfiguration.

Nach einem kürzlichen System-Upgrade auf dem Laptop trat beim Versuch, ssh an den Server zu senden (nennen wir es "myserver"), der folgende Fehler auf:

$ 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

Wenn Sie denselben Befehl mit straceausführen, wird der Fehler wie folgt angezeigt 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)

Funktioniert jedoch ping myservergut:

$ 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

Normalerweise habe ich lokale namedDNS-Weiterleitungsabfragen, aber der Fehler bleibt bestehen, wenn ich wieder direkt den DNS-Server des Routers verwende:

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

Der Fehler tritt nur sporadisch auf: Alle paar Minuten kann ich eine erfolgreiche Verbindung herstellen. Wenn ich erfolgreich eine Verbindung herstellen kann, connectwird eine IPv4-Adresse verwendet:

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

Der hostBefehl zeigt jedoch die gleiche IPv4-Adresse an, unabhängig davon, ob die Verbindung funktioniert oder unterbrochen ist:

$ host myserver                   
myserver has address 192.168.1.149

Nachdem ich diese Frage gelesen hatte , überlegte ich mir, die Schnittstelle manuell festzulegen ( ssh -v -v -F /dev/null -B en0 myserver). Dies beseitigt den Fehler, wenn er auftritt, ist jedoch keine dauerhafte Lösung für mich und erklärt nicht, warum der Fehler plötzlich auftrat.

Ich habe eine whileSchleife in meiner Shell verwendet, um die Zeit bis zur nächsten Sekunde zu bestimmen, in der sshvon "arbeiten" zu "nicht arbeiten" gewechselt wird, und ich konnte diese Ereignisse mit nichts in der Ausgabe von "korrelieren" journalctl, einschließlich der dhcpcdNachrichten.

Ich hatte dies ursprünglich auf Network Engineering gepostet, wo sich herausstellt, dass die Host-Konfiguration nicht zum Thema gehört. Auf dieser Seite hatte der Benutzer Ricky Beam eine Teilantwort gepostet:

Was auch immer die Auflösung von Hostnamen bewirkt, gibt eine oder mehrere verbindungslokale IPv6-Adressen zurück, die für die ausgewählte Schnittstelle nicht gültig sind, dh "any". Link-lokale Adressen müssen die Schnittstelle angeben - z. fe80: ...: 1% eth0

Warum Sie eine Link-Local-Adresse erhalten, ist unbekannt. Vielleicht könnten Leute, die mit Arch Linux vertraut sind, weitere Hilfe leisten.

Update: Es scheint ein Problem mit dem nscd"Name Service Cache Daemon" zu sein, das die Unterbrechung erklärt, die ich hatte (vermutlich aufgrund des Cache-Ablaufs). Es ist behoben mit:

sudo systemctl stop nscd.service

Wenn ich ncsd stoppe, sshkann die Verbindung über eine Link-Local-Adresse hergestellt werden. Diesmal gibt der connectAufruf jedoch auch meine primäre Schnittstelle "en0" an und dies ist erfolgreich:

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

Ich vermute, die verbleibende Frage (die ich separat stellen könnte) lautet: Ist dies ein Fehler in nscd und sollte ich nscd überhaupt verwenden?

Als ich einen Raspberry Pi ins Netzwerk brachte, manifestierte sich dieses Problem auf eine neue Art und Weise und ich konnte es endlich diagnostizieren.

Das Problem hängt mit zusammen systemd-resolved. Dies hat Auswirkungen auf andere Benutzer, siehe zum Beispiel Frage Ubuntus nslookup findet IP, aber ping nicht oder systemd aufgelöst fragt DNS -Server nicht nach lokaler Domain ab .

Ich hatte angenommen, dass ssh myserverdies eine DNS-Suche nach auslösen würde myserver. Dies ist jedoch auf meinem System nicht der Fall. Hier ist die Standardeinstellung nsswitch.conf:

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

Die resolveKomponente ist systemd-resolvedein Lennart Poettering-Projekt zur Implementierung der Zeroconf- Protokolle Multicast DNS und Link-Local Multicast Name Resolution .

Dies [!UNAVAIL=return]bedeutet, dass, wenn systemd-resolvedverfügbar, die DNS-Hostauflösung niemals verwendet wird. In der Regel ist dies kein Problem, da systemd-resolvedauch DNS-Abfragen erstellt werden können. Allerdings tut es dies anscheinend nicht für Single-Label-Hostnamen wie myserver, auch wenn sich der DNS-Server auf meinem lokalen Router befindet (192.168.1.1). Dies liegt daran, dass Single-Label-Hostnamen nicht dem externen Netzwerk zugänglich gemacht werden sollten, wie von Lennart in diesem Github-Thread erläutert .

Dies erklärt die Tatsache, dass host myservereine IPv4-Adresse (vom Router) und ssh myservereine IPv6-Adresse (vom Multicast-DNS oder LLNR, nicht sicher, welche) erzeugt wurden.

Das hat mich verwirrt, weil ich nie etwas über Multicast-DNS, LLNR oder IPv6 gelernt habe. Ich habe nie etwas über diese Technologien gelernt, weil ich der Meinung war, dass die vertrauten Technologien von IPv4 und DNS für mich ausreichen.

Offensichtlich systemd-resolvedist es nicht nur notwendig, Zeroconf-Anfragen zu erstellen, sondern auch, um darauf zu antworten. Der Raspberry Pi, den ich in mein Netzwerk gebracht habe systemd-resolved, wurde aus irgendeinem Grund angehalten. Obwohl ich den Hostnamen mit hostund nachschlagen konnte dig, konnte ich ihn nicht über sshoder anzeigen ping:

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

Dies führte mich zum ersten Ask Ubuntu-Fehlerbericht, der mich zur Lösung führte. Wenn ich systemd-resolvedauf dem Pi anfange, dann kann ich pingund kann sshes. Wenn ich jedoch systemd-resolved lokal deaktiviere, kann ich auch pingund sshzum Pi.

Im Moment habe ich gerade systemd-resolvedauf allen meinen Systemen deaktiviert ,

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

da dies Probleme mit GNU libc zu verursachen scheint nscdund ich mich mit Technologien wie IPv6, mDNS und LLNR auseinandersetzen muss, die ich derzeit nicht benötige - da meine Computer alle an einen Basis-Consumer-Router angeschlossen sind, der vertraute Technologien von bietet DNS und NAT sind sofort einsatzbereit.

Vielen Dank an diejenigen, die meine ursprüngliche Frage kommentiert haben, aber am Ende war es nicht erforderlich, sich ein ULA-Präfix zu konfigurieren oder eine globale IPv6-Konnektivität oder beides über eine Einstellung in Ihrem Heimrouter zu erhalten, wenn dies kein vollständiges Teil ist von **** "oder" um Ihren ISP anzuschreien ". Ich musste nur ein paar von Lennarts neuer Software deaktivieren, um mich von den neuesten Entwicklungen zu befreien. Im Github-Thread wird diskutiert, ob sich die Software tatsächlich richtig verhält, aber ich befinde mich in derselben Position wie viele andere Benutzer: Nachdem ich stundenlang herausgefunden habe, dass dies systemd-resolvedder Schuldige ist, würde ich lieber nicht mehr Stunden damit verbringen, es zu versuchen Verstehe, wie man das Problem behebt, wenn das Deaktivieren so einfach ist.