Warum zeigt SSH das Protokoll in netstat als tcp6 * und * tcp an?

$ netstat -nat
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN     
tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN     
tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN     
tcp6       0      0 :::22                   :::*                    LISTEN  

Warum gibt es zwei Datensätze von Port 22 ( :::22und 0.0.0.0:22) und warum verwendet einer das Protokoll als tcpund der andere alstcp6

Dies ist unter Ubuntu 12.04.4

Standardmäßig sshdwerden IPv4 und IPv6 verwendet. Sie können das Protokoll, das sshd verwendet, über die AddressFamilyDirektive in konfigurieren/etc/ssh/sshd_config

Für ipv4 & ipv6 (Standard)

AddressFamily any

Nur für IPv4

AddressFamily inet

Nur für IPv6

AddressFamily inet6

Nachdem Sie Änderungen vorgenommen haben, um sshd_configneu zu starten, sshddamit die Änderungen wirksam werden.

Eigentlich ist es etwas interessanter

Selbst wenn Sie IPv6 vollständig deaktivieren, werden einige Sockets aus seltsamen Kernelgründen grundsätzlich als "TCP6 / UDP6" identifiziert.

Ich habe es bemerkt, nachdem ich netstat auf einem Android-Telefon ausgeführt habe, das mit einem 3G-Netzwerk verbunden war, ohne die IPv6-Unterstützung zu beeinträchtigen (in den APN-Einstellungen deaktiviert und vom Netzbetreiber ausdrücklich nicht unterstützt).

Nachdem ich gesehen hatte, dass die TCP6-Verbindungen von WhatsApp irgendwie bestehen bleiben, begann ich zu recherchieren und fand diesen Link: https://blog.codecentric.de/de/2014/04/note-netstat/

Es ist möglich, nur ::IPv4 und IPv6 zu binden und zu sprechen. Ich habe mich gefragt, warum einige Anwendungen, einschließlich openssh, dies nicht nutzen.

Dieser Abschnitt über IPv6 im FreeBSD-Entwicklerhandbuch enthält einige interessante Kommentare, die relevant sein können:

Es sieht so aus, als ob RFC2553 zu wenig über das Problem der Platzhalterbindung spricht, insbesondere über das Problem mit dem Portspeicherplatz, den Fehlermodus und die Beziehung zwischen der Platzhalterbindung AF_INET / INET6. Für diesen RFC kann es mehrere separate Interpretationen geben, die ihm entsprechen, sich jedoch unterschiedlich verhalten. Um eine tragbare Anwendung zu implementieren, sollten Sie also nichts über das Verhalten im Kernel annehmen. Die Verwendung von getaddrinfo (3) ist der sicherste Weg. Probleme mit dem Portnummernraum und der Platzhalterbindung wurden Mitte März 1999 auf der IPv6imp-Mailingliste ausführlich erörtert, und es scheint, dass es keinen konkreten Konsens gibt (Mittel bis zu den Implementierern). Möglicherweise möchten Sie die Mailinglistenarchive überprüfen.

Wir können auch spekulieren, dass dieses Standardverhalten definiert wurde, als eine signifikante Anzahl von Systemen keine IPv6-Unterstützung hatte.