Selective and efficient logging of auth/connection information

Christian Winter bitpoet at
Sat Sep 19 02:47:00 EST 2009

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

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

More information about the openssh-unix-dev mailing list