bug#55335: openssh-service no longer listens on IPv6

[Christopher Baines]

Christopher Baines <mail@cbaines.net> 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

signature.asc
Description: PGP signature