Hi.

For *some* failed connections ssh seems to put no logging into auth.log anymore.
This can be quite security relevant when using e.g. fail2ban which relies on this.

Only some (types?) of connections seem to be affected, as I still see few IPs
that get banned by fail2ban.

But when I e.g. go to another host of mine, and try repeatedly to login, they don't
get banned (as nothing appears in the logs).
I tried both, hosts where a ~/.ssh/id_rsa* was in place and not.


Attached is my sshd's configuration. Please ask for mor information if you need any.


Cheers,
Chris.

Did this work as you expect in some previous version?  Which one?

If you use 'LogLevel VERBOSE', does that help?

Can you provide some examples of log messages that fail2ban is noticing
and banning?

Thanks,

Hi Colin.
Yes definitely,.. but unfortunately,.. I don not remember which one..
The problem isn't fail2ban,... it's that sshd doesn't log these attempts
at all...

But your idea (don't know why I didn't come up with this myself) with
LogLevel helped!

Now (with VERBOSE) messages like the following get logged to auth.log:
Jul 27 22:33:29 hilbert sshd[4542]: Set /proc/self/oom_score_adj to 0
Jul 27 22:33:29 hilbert sshd[4542]: Connection from 129.187.131.203 port
33023
Jul 27 22:33:30 hilbert sshd[4542]: Failed publickey for root from
129.187.131.203 port 33023 ssh2
Jul 27 22:33:30 hilbert sshd[4544]: Set /proc/self/oom_score_adj to 0
Jul 27 22:33:30 hilbert sshd[4544]: Connection from 129.187.131.203 port
33024
Jul 27 22:33:31 hilbert sshd[4544]: Failed publickey for root from
129.187.131.203 port 33024 ssh2

fail2ban also detects them now (I guess it goes for the "Failed
pub..")...

So the problem seems to be, that those messages are no longer logged in
the default LogLevel.


Cheers,
Chris.

severity 626112 important
thanks

You misunderstood me; I was asking for examples of the messages that
*were* logged, since you said that some addresses did get successfully
banned.  But never mind now.

The rules are that authentication results are logged at the default
level if any of the following is true:

  * the authentication was successful
  * the authentication attempt was for an invalid user
  * the number of failures on this connection >= MaxAuthTries/2
  * the authentication method was "password"

As far as I can tell, nothing relevant has changed in OpenSSH at all
recently.  Before MaxAuthTries was introduced, the required number of
failures was simply hardcoded to the same value.  Prior to that, the
rules have remained essentially unchanged since November 1999:

revno: 142
committer: damien
timestamp: Wed 1999-11-24 13:26:21 +0000
message:
   - Merged very large OpenBSD source code reformat
   - OpenBSD CVS updates
     - [channels.c cipher.c compat.c log-client.c scp.c serverloop.c]
       [ssh.h sshd.8 sshd.c]
       syslog changes:
       * Unified Logmessage for all auth-types, for success and for failed
       * Standard connections get only ONE line in the LOG when level==LOG:
         Auth-attempts are logged only, if authentication is:
            a) successfull or
            b) with passwd or
            c) we had more than AUTH_FAIL_LOG failues
       * many log() became verbose()
       * old behaviour with level=VERBOSE

Given how long this behaviour has been in place, and that there's a
straightforward workaround by changing LogLevel, I don't think it's
reasonable to regard this bug as release-critical, so I'm downgrading
it.  You may have only started to notice this recently due to external
factors; for example, perhaps your attackers have started to use
authentication methods other than password?

Regards,

Ok,.. weird... maybe there's something I don't see or I forgot,... was
quite sure that it "worked" like that and I changed nothing,...
Nevertheless...
Yeah, that's probably ok.
I mean... failed authentications with public key are usually harmeless
anyway,... as you can't (well in practise) to brute force attacks there.

On the other hand failed pubkey auth tries _are_ in some way security
relevant, as they could be some form of [D]DoS... and that's where
fail2band would be at least somewhat handy.

Do you think it makes sense to ask Damaien to change the default
behaviour here?
Actually I noticed it when testing myself some improved iptables rules
from a remote host...


Cheers,
Chris.