Bug 2326 - INFO logging fails for client with mis-configured DNS
Summary: INFO logging fails for client with mis-configured DNS
Status: CLOSED WORKSFORME
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: sftp-server (show other bugs)
Version: 5.3p1
Hardware: amd64 Linux
: P5 security
Assignee: Assigned to nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-12-06 07:30 AEDT by paul
Modified: 2021-03-04 09:54 AEDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description paul 2014-12-06 07:30:09 AEDT
I'm running an openssh server with internal-sftp and an sftponly group whose members can only sftp into a chroot environment. I've specified INFO level logging and added a rule to rsyslog so that I get file level event logging.

One client connected and I didn't get any logging for opendir, closedir, open or close events. I did get a reverse mapping error:

    2014-11-24 13:23:06 host1 sshd[7527]: reverse mapping checking getaddrinfo for a-b-c-d-static.hfc.comcastbusiness.net [a.b.c.d] failed - POSSIBLE BREAK-IN ATTEMPT!
    2014-11-24 13:23:12 host1 sshd[7527]: Accepted publickey for bob from a.b.c.d port 56663 ssh2
    2014-11-24 13:23:12 host1 sshd[7527]: pam_unix(sshd:session): session opened for user bob by (uid=0)
    2014-11-24 13:23:12 host1 sshd[7536]: subsystem request for sftp

I was able to reproduce this behavior by setting up an instance of bind9 with mismatched A and PTR entries.

Setting "UseDNS=no" in sshd_config seems to be the workaround.

I realize that UseDNS=no is or will be the default, and that there's a standing feature request regarding sftp-server logging; I'm reporting this in case someone thinks the behavior merits investigation. Misconfigured client DNS is no reason to suppress event logging.
Comment 1 Damien Miller 2015-04-17 23:35:26 AEST
I'm pretty sure that the DNS warnings are not the cause of the missing logs - we certainly don't suppress logs after that message.

Could you try reproducing this with a recent sshd? There have been quite a few improvements in how log messages are handled.
Comment 2 Damien Miller 2020-01-26 00:41:09 AEDT
~5yrs with no followup = no bug
Comment 3 Damien Miller 2021-03-04 09:54:24 AEDT
close bugs that were resolved in OpenSSH 8.5 release cycle