Por que o SSH mostra o protocolo como tcp6 * e * tcp no 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 que existem dois registros da porta 22 ( :::22e 0.0.0.0:22) e por que um usa o protocolo como tcpe o outro comotcp6

Isso está no Ubuntu 12.04.4

Por padrão, sshdusa ipv4 e ipv6. Você pode configurar o protocolo que o sshd usa por meio da AddressFamilydiretiva em/etc/ssh/sshd_config

Para ipv4 e ipv6 (padrão)

AddressFamily any

Apenas para ipv4

AddressFamily inet

Apenas para ipv6

AddressFamily inet6

Depois de fazer alterações para sshd_configreiniciar, sshdas alterações serão efetivadas.

Na verdade, é um pouco mais interessante

Basicamente, mesmo se você desabilitar completamente o IPv6, alguns soquetes serão identificados como "TCP6 / UDP6" devido a curiosos motivos do kernel.

Percebi isso depois de executar o netstat em um telefone Android conectado a uma rede 3G sem receber suporte de IPv6 (desativado nas configurações de APN e explicitamente não suportado pela operadora)

Depois que vi que as conexões TCP6 do WhatsApp de alguma forma persistem, comecei a pesquisar e encontrei este link: https://blog.codecentric.de/en/2014/04/note-netstat/

É possível ligar ::e falar apenas sobre IPv4 e IPv6. Eu me perguntei por que alguns aplicativos, incluindo o openssh, não tiram vantagem disso.

Esta seção sobre IPv6 no manual do desenvolvedor do FreeBSD tem alguns comentários interessantes que podem ser relevantes:

Parece que o RFC2553 fala muito pouco no problema de ligação de curinga, especialmente no problema de espaço na porta, no modo de falha e no relacionamento entre a ligação de curinga AF_INET / INET6. Pode haver várias interpretações separadas para esse RFC que estejam em conformidade com ele, mas se comportem de maneira diferente. Portanto, para implementar aplicativos portáteis, você não deve assumir nada sobre o comportamento no kernel. Usar getaddrinfo (3) é a maneira mais segura. Os problemas de espaço de número de porta e ligação de curinga foram discutidos em detalhes na lista de discussão ipv6imp, em meados de março de 1999, e parece que não há consenso concreto (meios, até os implementadores). Você pode querer verificar os arquivos da lista de discussão.

Também podemos especular que esse comportamento padrão foi definido quando um número significativo de sistemas não tinha suporte ao IPv6.