Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 18 Oct 2019 10:36:09 -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:  <D0CEE83C-5885-4043-877E-0F388CB90CF2@gmail.com>
In-Reply-To: <246561E5-9E57-4CC2-B94C-4CE8C553D972@gmail.com>
References:  <100597e5-4491-f455-d247-59f5374ea6a4@sentex.net> <246561E5-9E57-4CC2-B94C-4CE8C553D972@gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
>=20
>> 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
>=20
> 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=99=
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=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.


Thanks,
--
Matt Garber





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D0CEE83C-5885-4043-877E-0F388CB90CF2>