ssh-chat defaults to IPv6, even when IPv4 listening address is specified

[zachyordy]

prompt> ssh-chat --bind=0.0.0.0:2022
Enter passphrase: 
Listening for connections on [::]:2022

prompt> sudo netstat -plunt | grep 2022
tcp6       0      0 :::2022                 :::*                    LISTEN      29542/ssh-chat

I don't see ssh-chat listening on IPv4. Is there a way to make this happen?

[shazow]

Hmm so it's not bindable from 0.0.0.0:2022 locally? That's frustrating. Honestly not sure what the problem is here, would appreciate any help with debugging. :)

[ghost]

I have found the same problem. But apparently, you need to create a net.Listener separately. The http package's ListenAndServe functions are for convenience, and are not a complete solution.

package main

import (
    "log"
    "net"
    "net/http"
)

func main() {
    sm := http.NewServeMux()
    sm.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        w.WriteHeader(200)
        w.Write([]byte("Hello!\r\n"))
    })

    l, err := net.Listen("tcp4", ":8080")
    if err != nil {
        log.Fatal(err)
    }
    log.Fatal(http.Serve(l, sm))
}

golang/go#5197

[ghost]

So I've changed line 19; https://github.com/shazow/ssh-chat/blob/master/sshd/net.go

    socket, err := net.Listen("tcp4", laddr)

[shazow]

Can anyone confirm if this is still a problem with v1.1? Check the latest binary release here: https://github.com/shazow/ssh-chat/releases

Please re-open the issue if its.

[iamdavidcz]

@shazow @zachyordy I believe that this issue is related to this Golang issue. However, it is closed and some people still may want ssh-chat listen on IPv4 network only. Currently it seems that the only option is to manually change the network to tcp4 here and recompile...

[shazow]

@iamdavidcz Thanks for the note. Could you expand on your scenario which requires to only use IPv4? This will help inform me how to best design the UX to accommodate. :)

[iamdavidcz]

@shazow Getting through above comments I can notice that some users may want use IPv4 only, but I don't know their exact scenarios and use cases. Maybe they just don't use IPv6 and binding to it by default may cause serious vulnerabilities. But that's just my guess :)

[iamdavidcz]

@shazow And it seems like ssh-chat is not the only project that has this issue:
kubernetes/kubernetes#88458

I can see two options here. The first one (probably easier) is adding --network option with the default tcp so that user can easily change it to tcp4 without recompiling the whole package and the second (more problematic) is parsing IP address and try to pick the right network with tcp as a fallback. What do you think?

[shazow]

I agree about the options but I don't want to speculate on the scenario, adding features blind like this can cause more harm than good. :) There are often alternative approaches once a scenario is revealed.

I appreciate you doing the research.

If this issue does not affect you specifically, then let's punt on it until someone else shows up with a scenario they're dealing with.

[iamdavidcz]

@shazow Let me get this as straight as possible: I believe that the current behavior is a bug and should be fixed.

Passing --bind 0.0.0.0:2022 will listen both on IPv4 and IPv6 which is wrong. IMHO ssh-chat shouldn't magically bind to IPv6 and this issue suggest that most people wouldn't expect that.

0.0.0.0 means all IPv4 addresses on the local machine (not both).

[shazow]

@iamdavidcz I understood what you said.

If you're looking to fix this regardless of how it affects ssh-chat usecases, then you want to take it upstream: https://github.com/golang/crypto/blob/3c4aac89819a5fdc28d906456729d3423fd46969/ssh/tcpip.go#L24

[shazow]

A non-breaking fix I'd consider here is maybe an optional tcp4:// prefix or something, and we could improve the logging output to mention it's listening on both ipv4 and ipv6 if you feel it's not obvious.

[iamdavidcz]

@shazow Yes, we definitely should improve logging as it is wrong too:

$ ssh-chat --bind 0.0.0.0:2022
Listening for connections on [::]:2022

But first of all, can we reopen this issue?

[zachyordy]

Quite frankly, I'm not 100% sure what's going on here. When I specify to bind to 0.0.0.0:2022, the output shows that it is Listening for connections on [::]:2022, which is IPv6 port 2022.

When I check netstat, it only shows that the ssh-chat program is listening on tcp6:

prompt> sudo netstat -plunt | grep ssh-chat
tcp6       0      0 :::2022                 :::*                    LISTEN      28639/./ssh-chat

However, when I try to actually connect to the host using IPv4, it works.

The two things to fix in my mind would be:

1. Fix output to reflect fact that ssh-chat is only listening on IPv4 (or listening on dual-stack if this is the case), and
2. (Not sure if possible) Find some way for netstat to reflect the correct listener state.

[iamdavidcz]

@zachyordy As I mentioned before, when you specify to bind to 0.0.0.0:2022 ssh-chat listens both on IPv4 and IPv6 which is wrong (it should listen on IPv4 only). Explanation why netstat shows that ssh-chat listens on tcp6 can be found here.

[shazow]

#348 here's an open issue for you, appreciate you volunteering on this.

[iamdavidcz]

@shazow Why did you create a new issue instead of reopen this one? Once again (and hopefully the last one): the root of the issue is not logging, but the fact that ssh-chat listens on both IPv4 and IPv6 whereas it should listen only on IPv4. The log output is incorrect too (should be Listening for connections on 0.0.0.0:2022 instead of Listening for connections on [::]:2022), but this is just a consequence of the root problem. Please reopen this issue.

[Low-power]

In fact it will trying to bind to an IPv6 address even IPv6 is disabled in entire system (no IPv6 address is configured), resulting in an error, even if something like --bind 0.0.0.0:2022 specified:

# ./ssh-chat --version
v1.9
# ./ssh-chat --verbose --identity /etc/ssh/ssh_host_rsa_key
Failed to listen on socket: listen tcp 0.0.0.0:2022: bind: can't assign requested address
# ./ssh-chat --verbose --identity /etc/ssh/ssh_host_rsa_key --bind 0.0.0.0:2022
Failed to listen on socket: listen tcp 0.0.0.0:2022: bind: can't assign requested address
# truss -f ./ssh-chat --verbose --identity /etc/ssh/ssh_host_rsa_key --bind 0.0.0.0:2222 2>&1 | grep bind
27188: bind(3,{ AF_INET6 [::1]:0 },28)		 ERR#49 'Can't assign requested address'
27188: bind(4,{ AF_INET6 [::ffff:127.0.0.1]:0 },28) = 0 (0x0)
27188: bind(3,{ AF_INET6 [::]:2222 },28)	 ERR#49 'Can't assign requested address'
Failed to listen on socket: listen tcp 0.0.0.0:2222: bind: can't assign requested address

The workaround is to bind to a valid IPv4 address other than 0.0.0.0:

# ./ssh-chat --verbose --identity /etc/ssh/ssh_host_rsa_key --bind 127.0.0.1:2022
Listening for connections on 127.0.0.1:2022
^CInterrupt signal detected, shutting down.
# ./ssh-chat --verbose --identity /etc/ssh/ssh_host_rsa_key --bind x.x.x.x:2022
Listening for connections on x.x.x.x:2022
^CInterrupt signal detected, shutting down.