¿Por qué SSH muestra el protocolo como tcp6 * y * tcp en 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  

¿Por qué hay dos registros del puerto 22 ( :::22y 0.0.0.0:22) y por qué uno usa el protocolo como tcpy el otro comotcp6

Esto está en Ubuntu 12.04.4

Por defecto sshdusa ipv4 e ipv6. Puede configurar el protocolo que sshd usa a través de la AddressFamilydirectiva en/etc/ssh/sshd_config

Para ipv4 e ipv6 (predeterminado)

AddressFamily any

Solo para ipv4

AddressFamily inet

Solo para ipv6

AddressFamily inet6

Después de realizar cualquier cambio, sshd_configreinicie sshdpara que los cambios surtan efecto.

En realidad, es un poco más interesante.

Básicamente, incluso si desactiva completamente IPv6, algunos sockets se identificarán como "TCP6 / UDP6" debido a razones curiosas del núcleo.

Lo noté después de ejecutar netstat en un teléfono Android que estaba conectado a una red 3G sin entintar el soporte de IPv6 (deshabilitado en la configuración de APN y explícitamente no admitido por el operador)

Después de ver que las conexiones TCP6 de WhatsApp de alguna manera persisten, comencé a investigar y encontré este enlace: https://blog.codecentric.de/en/2014/04/note-netstat/

Es posible enlazar solo ::y hablar tanto IPv4 como IPv6. Me he preguntado por qué algunas aplicaciones, incluida openssh, no aprovechan esto.

Esta sección sobre IPv6 en el manual para desarrolladores de FreeBSD tiene algunos comentarios interesantes que pueden ser relevantes:

Parece que RFC2553 habla muy poco sobre el problema de enlace comodín, especialmente sobre el problema de espacio de puerto, modo de falla y relación entre enlace comodín AF_INET / INET6. Puede haber varias interpretaciones separadas para este RFC que se ajustan a él pero se comportan de manera diferente. Por lo tanto, para implementar una aplicación portátil, no debe suponer nada sobre el comportamiento en el núcleo. Usar getaddrinfo (3) es la forma más segura. Los problemas de espacio de números de puerto y enlace de comodines se discutieron en detalle en la lista de correo de ipv6imp, a mediados de marzo de 1999 y parece que no existe un consenso concreto (medios, hasta los implementadores). Es posible que desee consultar los archivos de la lista de correo.

También podemos especular que este comportamiento predeterminado se definió cuando un número significativo de sistemas no tenía soporte para IPv6.