On 10/18/2019 10:36 AM, Matt Garber wrote: >>> 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 ---Mike _______________________________________________ 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"