>>>> Does anyone know what the cause is of this fail message ? >>>> >>>> (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234793) >>>> >>>> its triggered by a normal ssh key'd login, but sshd is running with >>>> VERBOSE logging. >>>> >>>> sshd[63290]: Failed unknown for testuser1 from 192.168.xx.yyy port >>>> 60643 ssh2 ? >>>> >>>> The user is able to login no problem, but the error message is bubbling >>>> up in our HIDS. We had to white list it, but it would be useful to >>>> understand exactly why and what is failing. >>>> >>>> —Mike >>> It’s one of the other SSH authentication types (e.g., GSSAPI, password, >>> etc.) which is in the processing order before public key. I’m assuming >>> you’re seeing that ‘failure’ immediately before your successful key >>> authentication in auth.log; I actually had to switch back to INFO for >>> logging because that ‘failure’ trips up sshguard which kicks in and blocks >>> the IP despite the public key auth succeeding right after whichever other >>> auth type is tried and fails. >>> >>> (Unfortunately, I wasn’t able to determine which specific other >>> authentication type was being tried first, since moving logging back to >>> INFO resolved my immediate issue of getting blocked by sshguard before >>> successfully processing my key.) >> I’d also like to point out that whatever authentication method is now being >> tried first was a change from 11.3-RELEASE, as I didn’t encounter that >> ordering issue in my VERBOSE logs triggering sshguard until after upgrading >> to 12.0-RELEASE. I always have password auth disabled (only use public >> keys), but also tried explicit disable statements for GSSAPI and the several >> other auth types I could think of, but unfortunately wasn’t able to >> determine which auth type that log line corresponded to. It could also be an >> auth type that was previously used, but sshd in 12.0-RELEASE re-ordered the >> processing sequence to try it before public keys. > > If you crank it up to debug3, its even stranger. There are a two failed > unknowns, and one is after the key'd authentication has been accepted. > The client I am using, (SecureCRT) has only Public Key auth and has > everything else disabled. > > Oct 18 10:35:35 ryzen-r12 sshd[63439]: debug1: trying public key file > /home/testuser1/.ssh/authorized_keys > Oct 18 10:35:35 ryzen-r12 sshd[63439]: debug3: mm_request_send entering: > type 51 > Oct 18 10:35:35 ryzen-r12 sshd[63439]: debug1: fd 4 clearing O_NONBLOCK > Oct 18 10:35:35 ryzen-r12 sshd[63439]: Failed unknown for testuser1 from > 192.168.43.29 port 63170 ssh2 > Oct 18 10:35:35 ryzen-r12 sshd[63439]: debug1: > /home/testuser1/.ssh/authorized_keys:2: matching key found: RSA > SHA256:xxxxxx
I think it must be something that the server is trying even if the client doesn’t actually send that type, since I also tested with OpenSSH on the client end (macOS 10.14, OpenSSH_7.9p1, LibreSSL 2.7.3) only specifying public key authentication – with all of its other auth types disabled – and still had the same problem on my upgraded 12.0-RELEASE systems. Thanks, -- Matt Garber _______________________________________________ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
