# see explanation below severity 429243 wishlist retitle 429243 special syslogd configuration required in order to log messages from network child thanks
On Sat, Jun 16, 2007 at 09:43:36AM -0400, Brandon Craig Rhodes wrote: > Package: openssh-server > Version: 1:4.6p1-1 > Severity: grave > > The openssh-server "unstable" upgrade yesterday made sshd stop logging > failures correcty to syslog. If I successfully log in, then a message > is correctly printed in /var/log/auth.log like these: > > Jun 16 09:04:39 ten22 sshd[28070]: Accepted password for brandon from ... > port 49393 ssh2 > Jun 16 09:07:42 ten22 sshd[28496]: Accepted publickey for brandon from ... > port 38827 ssh2 > > But my many attempts to log in that resulted, on the client end, in > the message: > > Permission denied (publickey). > > left absolutely *no* trace in the logs! I verified that the SSH > server was indeed answering these connections (and that they weren't > getting routed to the wrong machine or anything) by stopping it, > running it in debug mode (/usr/sbin/sshd -e -f) and then also under > strace(1), and seeing that it was indeed receiving the connection and > responding with a refusal to allow a connection. > > Now: why was it refusing to let me log on with a password? Password > logins had been succeeding since the machine was installed long ago; > what had changed? Well, I am not sure whether SSH has changed or my > config files (I will check my backups), but I did find the directive > in /etc/ssh/sshd_config: > > PasswordAuthentication no > > How did that get there!? And if it were there before, why was SSH > letting me in? I had better check my backups right now, because I > guess that's an important question. [Three minute pause.] Well, how > odd! "PasswordAuthentication no" has been my setting for as long as I > have been keeping backups, and yet SSH always permitted them! This part of your bug report is certainly grave, and is bug #428968. It wasn't PasswordAuthentication that was letting you log in with a password before, but ChallengeResponseAuthentication, which I bet you have commented out; the default was supposed to be yes, but wasn't working properly. I'll have that fixed soon. > Anyway, my real worry here - and the reason I have put "grave" as the > severity level - is that login failures appear to no longer be sent to > syslog, which seems a huge problem in the daemon that is protecting my > system at its most fundamental level. Though, I must admit, it does > still seem to log failures *if* the method is password authentication; > but its not logging public-key-based failures still seems worrisome > enough to warrant immediate attention. Most such failures are logged if you put 'LogLevel VERBOSE' in the configuration file. Upstream appear to be happy with this state of affairs. There are some situations (mainly "postponed" authentications, I believe; for instance, if you fail to provide a passphrase for your public key at the client side so that the client has to abort the authentication attempt, that winds up as a postponed authentication) where log messages don't make it to syslog in the current Debian configuration. http://bugzilla.mindrot.org/show_bug.cgi?id=906 discusses this and notes that the system's syslogd should be configured to listen on /dev/log in the network child's chroot (/var/run/sshd/dev/log in Debian). This can be done by passing '-a /var/run/sshd/dev/log' to syslogd (see /etc/default/syslogd), but something also needs to mkdir /var/run/sshd/dev before syslogd starts in order to make this work. Joey, is there any way that we could arrange to configure Debian's syslogd such that it also listens on /var/run/sshd/dev/log if openssh-server is installed? Perhaps somewhere that openssh-server could drop a configuration file fragment ... -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
