sshd [net] is chrooted and cannot access /dev/log. This means syslog() cannot talk to syslogd and all messages logged by this process are rerouted to the nearest blackhole. The problem is not apparent at the default LogLevel (in fact things look better this way at the first glance because superfluous invocations of auth_log() in the child are suppresed). Some implementations of syslogd are able to listen on additional sockets but 1. other implementations lack this feature, 2. one has to mess with syslogd configuration when sshd is installed. An alternative approach would be to send log messages to the monitor and let the monitor forward them to syslogd. I've got a PoC implementation and it appears to work. What do you think?
I think it is best to make syslogd listen in /var/empty/dev/log, this is what OpenBSD does - lots of daemons chroot there, so it makes sense to have a log socket for all of them.
dev/log in /var/empty => not empty anymore :) There are syslogd's out there that cannot listen on multiple sockets...Are people using those systems (I think you can name any commercial unix) supposed to replace their standard syslogd? Or run an extra instance of syslogd? (Or pretend the problem does not exist?)
We won't send log messages to the monitor - that is very, very wrong. Systems without a syslogd that is able to listen in multiple places can (IMO) either cope with the loss, fix their syslogd, run a real syslogd (there are plenty of free ones that support multiple log sockets) or forego privsep. OTOH the README should mention that /var/empty should have a /dev/log if people want logging messages from the [net] process.
Not ideal, but on systems that only support one /dev/log socket you can do this: # mkdir /var/empty/dev # mv /dev/log /var/empty/dev/log # ln -s /var/empty/dev/log /dev/log
I understand it is against the design goals of privsep to add "unnecessary" functions, like a syslogd proxy, to the monitor. This is wrong, sure. But, for the record, what makes it "very, very wrong" (i.e. 2 orders of magnitude worse than "wrong")? I mean, is there anything besides the violation of design goals?
The point of privsep is to keep this sort of arbitrary untrusted data away from the privileged process.
Created attachment 1104 [details] suppress duplicate log messages I just committed this patch, which fixes the double logging and adds some logging on the monitor side for failed authentications. I know if still misses "postponed" authentications (which may not be worth the effort) but is anything else missing?
Please note that the intent of Darren's patch is to suppress duplicate logs, not eliminate the need for operating systems to configure their syslogds to listen at /var/log/empty/dev/log (or similar) as the [net] child still logs events of interest.
Closing: we recommend that syslogd listens in /var/empty/dev/log (or equivalent) so all messages from the unprivileged process are captured. This is similar to named, postfix and other daemons that operate in a chroot.
With the release of 4.4, we believe that this bug is now closed. For information about the release please see http://www.openssh.com/txt/release-4.4 .