Perché SSH mostra il protocollo come tcp6 * e * tcp in netstat?

$ 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  

Perché ci sono due record della porta 22 ( :::22e 0.0.0.0:22) e perché uno usa il protocollo come tcpe l'altro cometcp6

Questo è su Ubuntu 12.04.4

Per impostazione predefinita sshdutilizza ipv4 e ipv6. Puoi configurare il protocollo che sshd usa attraverso la AddressFamilydirettiva in/etc/ssh/sshd_config

Per ipv4 e ipv6 (impostazione predefinita)

AddressFamily any

Solo per ipv4

AddressFamily inet

Solo per ipv6

AddressFamily inet6

Dopo aver apportato le modifiche per sshd_configriavviare sshdper rendere effettive le modifiche.

In realtà, è leggermente più interessante

Fondamentalmente, anche se disabiliti completamente IPv6, alcuni socket verranno identificati come "TCP6 / UDP6" a causa di curiosi motivi del kernel.

L'ho notato dopo aver eseguito netstat su un telefono Android collegato a una rete 3G senza inchiostrazione del supporto IPv6 (disabilitato nelle impostazioni APN e esplicitamente non supportato dal gestore telefonico)

Dopo aver visto che le connessioni TCP6 di WhatsApp persistono in qualche modo, ho iniziato a ricercare e ho trovato questo link: https://blog.codecentric.de/en/2014/04/note-netstat/

È possibile collegarsi solo ::e parlare sia su IPv4 che su IPv6. Mi sono chiesto perché alcune applicazioni, incluso openssh, non ne traggano vantaggio.

Questa sezione su IPv6 nel manuale degli sviluppatori di FreeBSD ha alcuni commenti interessanti che potrebbero essere rilevanti:

Sembra che RFC2553 parli troppo poco sul problema del bind jolly, in particolare sul problema dello spazio porta, sulla modalità di errore e sulla relazione tra bind jolly AF_INET / INET6. Ci possono essere diverse interpretazioni separate per questo RFC che si conformano ad esso ma si comportano diversamente. Quindi, per implementare un'applicazione portatile non dovresti assumere nulla sul comportamento nel kernel. L'uso di getaddrinfo (3) è il modo più sicuro. Lo spazio del numero di porta e i problemi di associazione con caratteri jolly sono stati discussi in dettaglio nella mailing list di ipv6imp, a metà marzo 1999 e sembra che non vi sia consenso concreto (cioè fino agli implementatori). Potresti voler controllare gli archivi della mailing list.

È inoltre possibile ipotizzare che questo comportamento predefinito sia stato definito quando un numero significativo di sistemi non disponeva del supporto IPv6.