Why does SSH show protocol as tcp6 *and* tcp in netstat?

Question

$ 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  

Why are there two records of port 22 (:::22 and 0.0.0.0:22) and why does one use protocol as tcp and the other as tcp6

This is on Ubuntu 12.04.4

Answer 1

By default sshd uses ipv4 and ipv6. You can configure the protocol sshd uses through the AddressFamily directive in /etc/ssh/sshd_config

For ipv4 & ipv6 (default)

AddressFamily any

For ipv4 only

AddressFamily inet

For ipv6 only

AddressFamily inet6

After you make any changes to sshd_config restart sshd for the changes to take effect.

Answer 2

Actually, it's slightly more interesting

Basically, even if you completely disable IPv6, some sockets will get identified as "TCP6/UDP6" due to curious kernel reasons.

I noticed it after I ran netstat on an android phone that was connected to a 3G network without an inking of IPv6 support (disabled in APN settings and explicitly not supported by carrier)

After I saw that TCP6 connections of WhatsApp somehow persist, I started researching and found this link: https://blog.codecentric.de/en/2014/04/note-netstat/

Answer 3

It is possible to bind only on :: and talk both IPv4 and IPv6. I have wondered why some applications, including openssh, do not take advantage of this.

This section about IPv6 in the FreeBSD developers' handbook has some interesting commentary that may be relevant:

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.

We may also speculate that this default behavior was defined when a significant number of systems did not have IPv6 support.