Date: Fri, 18 Oct 2019 10:55:31 -0400 From: Matt Garber <matt.garber@gmail.com> To: mike tancsa <mike@sentex.net> Cc: freebsd-stable@freebsd.org Subject: Re: SSH error messages (bug id=234793) ) RELENG_12 Message-ID: <63F56530-DA75-425B-9399-6D41DF0B119E@gmail.com> In-Reply-To: <07bac044-7506-e4a9-9d6a-f89aade926b4@sentex.net> References: <100597e5-4491-f455-d247-59f5374ea6a4@sentex.net> <246561E5-9E57-4CC2-B94C-4CE8C553D972@gmail.com> <D0CEE83C-5885-4043-877E-0F388CB90CF2@gmail.com> <07bac044-7506-e4a9-9d6a-f89aade926b4@sentex.net>
next in thread | previous in thread | raw e-mail | index | archive | help
>>>> Does anyone know what the cause is of this fail message ? >>>>=20 >>>> (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D234793) >>>>=20 >>>> its triggered by a normal ssh key'd login, but sshd is running with >>>> VERBOSE logging.=20 >>>>=20 >>>> sshd[63290]: Failed unknown for testuser1 from 192.168.xx.yyy port >>>> 60643 ssh2 ? >>>>=20 >>>> 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. >>>>=20 >>>> =E2=80=94Mike >>> It=E2=80=99s one of the other SSH authentication types (e.g., = GSSAPI, password, etc.) which is in the processing order before public = key. I=E2=80=99m assuming you=E2=80=99re seeing that =E2=80=98failure=E2=80= =99 immediately before your successful key authentication in auth.log; I = actually had to switch back to INFO for logging because that = =E2=80=98failure=E2=80=99 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. >>>=20 >>> (Unfortunately, I wasn=E2=80=99t 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=E2=80=99d also like to point out that whatever authentication = method is now being tried first was a change from 11.3-RELEASE, as I = didn=E2=80=99t 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=E2=80=99t 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. >=20 > 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. >=20 > 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=E2=80=99t 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 =E2=80=93 with all of its = other auth types disabled =E2=80=93 and still had the same problem on my = upgraded 12.0-RELEASE systems. Thanks, -- Matt Garber
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?63F56530-DA75-425B-9399-6D41DF0B119E>