Re: bin/60512: sshd: hosts.deny and hosts.allow for NetBSD 10 not working for 11

["Rin Okuyama via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR bin/60512; it has been noted by GNATS.

From: Rin Okuyama <rokuyama.rk%gmail.com@localhost>
To: Taylor R Campbell <riastradh%NetBSD.org@localhost>,
 Martin Husemann <martin%duskware.de@localhost>, Brian Buhrow <buhrow%NetBSD.org@localhost>,
 "christos%netbsd.org@localhost" <christos%NetBSD.org@localhost>
Cc: gnats-bugs%NetBSD.org@localhost, netbsd-bugs%NetBSD.org@localhost
Subject: Re: bin/60512: sshd: hosts.deny and hosts.allow for NetBSD 10 not
 working for 11
Date: Wed, 29 Jul 2026 17:19:59 +0900

 Thank you guys for your comments!
 
 On 2026/07/28 22:18, Taylor R Campbell wrote:
 >> Date: Tue, 28 Jul 2026 12:20:15 +0200
 >> From: Martin Husemann <martin%duskware.de@localhost>
 >>
 >> If that change is not acceptable, this needs to be checked by
 >> postinstall(8). "postinstall check" could just fail with a message
 >> pointing the admin at what manual fix would work.
 > 
 > That's absurd; the introduction of an internal privilege separation
 > measure in the implementation of sshd should not reinterpret the
 > operator's intent!
 > 
 > This was previously discussed at:
 > 
 > https://mail-index.netbsd.org/current-users/2025/01/06/msg045945.html
 
 Ah, I missed this discussion.
 
 > As a result of that discussion, we updated our local patch for libwrap
 > support to check _both_ `sshd-session' and `sshd':
 > 
 > https://mail-index.netbsd.org/source-changes/2025/01/08/msg155130.html
 > 
 (snip)
 > 
 > https://nxr.netbsd.org/xref/src/crypto/external/bsd/openssh/dist/sshd-session.c?r=1.13#106
 > 
 > However, I suspect that logic only works for hosts.deny, not for
 > hosts.allow.
 
 Yes. It doesn't as described in this PR.
 
 > Frankly, I don't think we should use the name sshd-session at all;
 > it's an internal implementation detail, not the name of the service
 > users are configuring.  We should just fix openssh to use the name
 > "sshd" again.
 
 I'm leaning toward this option. Christos, how do you think as
 the maintainer of our in-tree OpenSSH?
 
 Thanks,
 rin