SSH "failed none" syslog entries causing Linux failed login counter to advance.
Chris
counter advances by 1 before the user even enters a password.
When looking at the syslog entries (in debug mode) it shows a failed
login attempt while the user is still at the password prompt. I assume
that it is from SSH attempting either a host-based or null password
before requesting a password and the failure is being logged (and
triggers the pam_tally counter).
I have turned off rhost and even public key authentication in both the
client and server configuration files. I've even modified the clients
preferred authentication order to remove the host-based and publickey
methods.
Here are the "sanitized" log entries:
debug1: PAM Password authentication for "USERNAME" failed[7]:
Authentication failure
debug3: mm_answer_authpassword: sending result 0
debug3: mm_request_send entering: type 11
Failed none for USERNAME from xxx.xxx.xxx.xxx port 33370 ssh2
What is SSH attempting before the password is entered, and how do I
turn it off?
Thank you
-Chris
Richard E. Silverman
You don't say what SSH software you're using. However, the quoted debug
messages indicate you're talking about OpenSSH on the server, so I'll
assume that.
> I am trying to troubleshoot why on my Linux systems, the faillog
> counter advances by 1 before the user even enters a password...
> ... What is SSH attempting before the password is entered
The OpenSSH server always attempts authentication with a null password,
which it takes as a sign that no authentication is needed for the account
in question. It does this as soon as the authentication process begins,
in both protocols, and not in response any "real" authentication request
from the client (although it does happen in response to the "none" request
in protocol 2). OpenSSH will only allow such access if the sshd_config
flag PermitEmptyPassword is set; unfortunately, the way the code is
written, it performs the password test in any case, and thus shows up to
PAM as a failure.
I consider this a bug: there's no need for this failure to be flagged to
the sysadmin, and OpenSSH should avoid testing the null password if
PermitEmptyPassword is false. Of course, such a failure *should* be
reported if it happens in response to an actual password authentication
request from the client.
> ... and how do I turn it off?
There's no option to change this; you'll have to hack the code.
--
Richard Silverman
r...@qoxp.net
Darren Tucker
Richard E. Silverman <r...@qoxp.net> wrote:
>> I am trying to troubleshoot why on my Linux systems, the faillog
>> counter advances by 1 before the user even enters a password...
[snip discussion of "none" auth and trying to login with no password]
>I consider this a bug: there's no need for this failure to be flagged to
>the sysadmin, and OpenSSH should avoid testing the null password if
>PermitEmptyPassword is false. Of course, such a failure *should* be
>reported if it happens in response to an actual password authentication
>request from the client.
There has been some discussion about leaking information (ie the system
responds differently if the account doesn't exist, or you get the
password right but aren't allowed to log on).
I'm not sure either way, I just know that 3.6.1p2 isn't right no matter
which side of the argument you take.
>> ... and how do I turn it off?
>
>There's no option to change this; you'll have to hack the code.
There's a patch attached to the Debian bug for this, near the bottom.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=192207
--
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.