pkg/60563: exposed sshd w/o password-login causes sshd-auth looping

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

>Number:         60563
>Category:       pkg
>Synopsis:       exposed sshd w/o password-login causes sshd-auth looping
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    pkg-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Aug 09 13:10:00 +0000 2026
>Originator:     Havard Eidnes
>Release:        NetBSD 10.1
>Organization:
	I try...
>Environment:
System: NetBSD castor.urc.uninett.no 10.1 NetBSD 10.1 (GENERIC) #0: Mon Dec 16 13:08:11 UTC 2024  mkrepro%mkrepro.NetBSD.org@localhost:/usr/src/sys/arch/amd64/compile/GENERIC amd64
Architecture: x86_64
Machine: amd64
>Description:
	I manage a few exposed sshd installations.

	They are all configured to dis-allow password or keyboard-interactive
	authentication methods, in other words: they insist on ssh key-based
	logins, via:

PasswordAuthentication no
KbdInteractiveAuthentication no

	in /etc/ssh/sshd_config.

	Also, these sshd's are from the pkgsrc security/openssh package,
	via /etc/rc.conf.d/sshd containing

command=/usr/pkg/sbin/sshd

	Of course these sshd's get probed by automated scanners, so
	I have installed "denyhosts" to get rid of the worst of it.

	But of course, some still manage to connect.  And a few of
	these again appear to expose a "resource consumption problem"
	at my end: some connections cause the sshd-auth process to
	enter a rather tight loop doing syscalls, in particular a
	loop with poll() and read().  An example demonstrating this
	is shown with "ktruss -R -p 6007":

  6007   6007 sshd-auth 0.000001846 poll(0x7f7fff737090, 0x1, 0xffffffff) = 1
  6007   6007 sshd-auth 0.000024690 read(0x5, 0x7f7fff73712f, 0x1) Err#35 EAGAIN
  6007   6007 sshd-auth 0.000002275 poll(0x7f7fff737090, 0x1, 0xffffffff) = 1
  6007   6007 sshd-auth 0.000001622 read(0x5, 0x7f7fff73712f, 0x1) Err#35 EAGAIN
  6007   6007 sshd-auth 0.000002040 poll(0x7f7fff737090, 0x1, 0xffffffff) = 1
  6007   6007 sshd-auth 0.000001593 read(0x5, 0x7f7fff73712f, 0x1) Err#35 EAGAIN
  6007   6007 sshd-auth 0.000001924 poll(0x7f7fff737090, 0x1, 0xffffffff) = 1

	This process is eventually culled by the main sshd, but only
	after it has spent 10 minutes CPU time on this activity.

	The file descriptor involved above (5) appears to be the TCP
	connection back to the scanner:

castor# fstat -n -p 6007
USER     CMD          PID   FD    DEV       INUM   MODE  SZ|DV R/W
sshd     sshd-auth   6007 root  168,1   48394025  40755    512 r 
sshd     sshd-auth   6007   wd  168,1   48394025  40755    512 r 
sshd     sshd-auth   6007    0  168,1   19910412  20666  2,2  rw
sshd     sshd-auth   6007    1  168,1   19910412  20666  2,2  rw
sshd     sshd-auth   6007    2  168,1   19910412  20666  2,2  rw
sshd     sshd-auth   6007    3* unix stream  0xfffffe850732db80 <-> 0xfffffe8c35cffd00
sshd     sshd-auth   6007    4* pipe 0xfffffe97e008eae0 -> 0xfffffe9a4520bbf8 w
sshd     sshd-auth   6007    5* internet stream tcp 45.176.232.161:36048 <-> 217.144.76.202:22
castor# netstat -f inet -n | egrep 45.176.232.161\|Q
Proto Recv-Q Send-Q  Local Address          Foreign Address        State
tcp        0     22  217.144.76.202.22      45.176.232.161.36048   ESTABLISHED
castor# 

	So ... admittedly I have not looked at the code of sshd-auth,
	but if it is programmed "correctly", poll() should not indicate
	that there is readable data on the FD in question, when the
	EAGAIN indicate there is not (evidently the FD is in non-blocking
	mode).  So currently it's a bit unclear whether this is a bug
	hiding inside sshd-auth or whether it's a NetBSD networking bug.

>How-To-Repeat:
	See above.

>Fix:
	That would be nice.