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).
signature.asc
Description: PGP signature
--- End Message ---