Selective and efficient logging of auth/connection information

[Peter Stuge]

Christian Winter wrote:
> each time anew with each minor update and check whether some odd
> change has been introduced into the log format.

I think you'll find that odd changes to the log messages are rare in
OpenSSH.

And yes, each time you update your software, you really do need to
check if all your assumptions still hold true. There's no shortcut..


> And the whole mix-and-filter setup brings with itself performance
> penalties which, in my personal opinion, could and should be
> reduced by a huge number.

It seems to me that mixing can be avoided to a high degree by using
syslog facility and level wisely.


>>> the neccessary parts from opensshd in a concise single-line format.
>>
>> So this would be the real addition - that sshd contains policy on
>> what the system should do.
>
> sshd should neither contain anything policylike, nor should it even
> be aware that there might be something like that. All I want is a
> performant, clean interface where I can fetch well-formated and
> -defined status changes.

What defines a status change? This is controlled by a policy. In
order for the setup to be as efficient as possible, this policy
must be within sshd. sshd doesn't want that.


> Though it should be the job of sshd to make its information available
> selectively, concisely and in a performance optimized and secure way.

I disagree on the selectively part.


> In a perfect world, I'd be able to tell sshd I want to be notified
> of successful logins, failed logins and perhaps other things like
> failed connection attempts.

So you want to describe a policy for sshd. sshd is not interested, it
has enough to do already and the policy can be implemented just as
well if not better outside of sshd.


> In the perfect world, even syslog running out of disk space
> wouldn't kill me, because I'd fetch all the neccessary information
> in-memory.

Why bother with logging to disk if you don't want to store the data?
This is why I made sure to mention that syslog-ng can use pipes.

Really, I think you can get much of what you request by using your
syslogd in a new way.

Maybe you NEED to store all data? Then you better make sure to always
have enough disk space..


> In the imperfect world I'm now in, I have syslog as a single point
> of failure

(as opposed to your new management software being the single point of
failure)


> and a constantly changing set of patterns that I have to monitor

(do sshd log messages really change that often?)


> The only place to change that seems to be in sshd, so for me the
> question is how, not if.

You are requesting a new management interface without spec and
without a suggested implementation. I think that will be ignored.


Now, the audit functionality you looked into is probably meant for
the very same purpose, so it seems like the best way forward might be
to find out how to make that work for you? I believe (small)
improvements there (with high impact) would be much better received.


//Peter