$ 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 ( :::22 e 0.0.0.0:22 ) e por que um usa o protocolo como tcp e o outro como tcp6
Isso está no Ubuntu 12.04.4
Por padrão sshd usa ipv4 e ipv6. Você pode configurar o protocolo sshd usa através da diretiva AddressFamily em /etc/ssh/sshd_config
Para ipv4 & ipv6 (padrão)
AddressFamily any
Apenas para o ipv4
AddressFamily inet
Apenas para o ipv6
AddressFamily inet6
Depois de fazer qualquer alteração em sshd_config restart sshd para que as alterações entrem em vigor.
Na verdade, é um pouco mais interessante
Basicamente, mesmo se você desabilitar completamente o IPv6, alguns sockets serão identificados como "TCP6 / UDP6" devido a razões curiosas do kernel.
Eu notei isso depois que executei o netstat em um telefone Android que estava conectado a uma rede 3G sem um suporte ao IPv6 (desativado nas configurações de APN e explicitamente não suportado pela operadora)
Depois de ver que as conexões TCP6 do WhatsApp persistem, comecei a pesquisar e encontrei este link: link
É possível ligar apenas em :: e falar em IPv4 e IPv6. Eu me pergunto por que alguns aplicativos, incluindo o openssh, não aproveitam isso.
Esta seção sobre o IPv6 no manual dos desenvolvedores do FreeBSD tem alguns comentários interessantes que podem ser relevantes:
It looks that RFC2553 talks too little on wildcard bind issue, especially on the port space issue, failure mode and relationship between AF_INET/INET6 wildcard bind. There can be several separate interpretation for this RFC which conform to it but behaves differently. So, to implement portable application you should assume nothing about the behavior in the kernel. Using getaddrinfo(3) is the safest way. Port number space and wildcard bind issues were discussed in detail on ipv6imp mailing list, in mid March 1999 and it looks that there is no concrete consensus (means, up to implementers). You may want to check the mailing list archives.
Também podemos especular que esse comportamento padrão foi definido quando um número significativo de sistemas não tinha suporte a IPv6.