Selective and efficient logging of auth/connection information

[Christian Winter]

Peter Stuge wrote:
> 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..
>   

That's why I'm trying for concise and fixed format (as in 'changes
there need to be announced in the changelog') instead of a format meant
to be interpreted by human eyes and that has no official spec.

>> 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 moment syslog has to look into the message the penalty's already
there. I agree that it can be lightened up to a certain point, but
with configuration efforts that are again based on assumptions about
the logging behaviour.

>>>> 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.
>   

sshd knows that anyway. Connected, successfully authenticated,
authentication failed, disconnected, these are stati inherent to
the ssh protocol. I'm not talking about making up new ones.

>> 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.
>   

I'd too if the places to do so weren't already there and
the program flow had to be changed to isolate them.

>> 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.
>   

It seems to be the 'as well if not better' part we're really disagreeing.
For me, there are a number of questions that decide that part, namely
- would I gain resources by implenting the functionality directly
 in sshd?
- would it impact maintainability of the sshd codebase?
- would it critically degrade sshd's performance?
- would it open up security holes in 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..
>   

If things were just that easy :)

>> 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)
>   

Nope, I'm not talking about a central be-all-and-log-all management
software which is heavily influenced by lots of different programs running
on the machine, just a single program that accomplishes a single task.

>> and a constantly changing set of patterns that I have to monitor
>>     
>
> (do sshd log messages really change that often?)
>   

Is there any reliable, change-tracked description of the log message
format?

>> 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.
>   

If that was so, it would not shine a bright light on ssh development.
Especially as I'm not requesting, but rather asking about general
thoughts and the best way to go if I wanted to implement such a thing.
> 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.
>   

I can do that, of course, but politeness and common sense made me
ask generic questions before jumping onto a moving train :)

Best Greetings
Chris