Christopher Baines writes: > This looks to be a recent regression, probably connected with the > shepherd now doing the listening, rather than sshd itself. > > Previously, you could use both IPv4 and IPv6. > > netstat -tlnp | grep sshd > tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 26683/sshd: /gnu/st > tcp6 0 0 :::22 :::* LISTEN 26683/sshd: /gnu/st > > Now though, it looks like with shepherd doing the listening, you can > only use IPv4. > > netstat -tlnp | grep 22 > tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1/guile > > > On an affected machine, you can reproduce this by trying to SSH over v6. > > cbaines@lakeside ~$ ssh 127.0.0.1 > The authenticity of host '127.0.0.1 (127.0.0.1)' can't be established. > ED25519 key fingerprint is SHA256:1wV7w84awrGv5ilP5e8k5ygIvSkXSJ6LIy3MnqZG2Jw. > This key is not known by any other names > Are you sure you want to continue connecting (yes/no/[fingerprint])? ^C > > cbaines@lakeside ~$ ssh ::1 > ssh: connect to host ::1 port 22: Connection refused > > > This isn't an issue if you're not using IPv6, but if you have a machine > only accessible via IPv6, then you can't ssh in. The main workaround > I've found is getting access via other means, then starting sshd > listening on a different port (as the shepherd is using 22). I've had another look at how this might be fixed. One workaround that seems to work is having the service just listen on an IPv6 socket as I believe Linux translates IPv4 connections to IPv6. The openssh system test seems to pass, and I believe this would fix not being able to connect over IPv6, although it seems likely that this would break things relying on IPv4 usage, like configuration based on specific IP addresses. I think the more rigerous approach would be to have shepherd listen on two sockets, one for IPv4 and another for IPv6. That's currently difficult though because of the above behaviour, the IPv6 socket blocks opening the IPv4 one. I've got a patch [1] to Guile that adds the constants needed for the setsockopt call and once that's possible, I believe the setsockopt call would need to happen in make-inetd-constructor. 1: https://lists.gnu.org/archive/html/guile-devel/2022-05/msg00007.html Without reverting to the previous behaviour, maybe the best way forward is to at least allow having the service listen via IPv6. That would mean those affected by the loss of IPv6 support could enable it, and would hopefully avoid breaking anyones configuration where they're relying on native IPv4 connections. I'll send a patch for this shortly. Chris