Date: Fri, 18 Oct 2019 10:44:40 -0400 From: mike tancsa <mike@sentex.net> To: Matt Garber <matt.garber@gmail.com> Cc: freebsd-stable@freebsd.org Subject: Re: SSH error messages (bug id=234793) ) RELENG_12 Message-ID: <07bac044-7506-e4a9-9d6a-f89aade926b4@sentex.net> In-Reply-To: <D0CEE83C-5885-4043-877E-0F388CB90CF2@gmail.com> References: <100597e5-4491-f455-d247-59f5374ea6a4@sentex.net> <246561E5-9E57-4CC2-B94C-4CE8C553D972@gmail.com> <D0CEE83C-5885-4043-877E-0F388CB90CF2@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?07bac044-7506-e4a9-9d6a-f89aade926b4>