Bug 689

Summary:	Improper reverse IP lookup
Product:	Portable OpenSSH	Reporter:	Andy Berkvist <berkvist>
Component:	sshd	Assignee:	OpenSSH Bugzilla mailing list <openssh-bugs>
Status:	CLOSED WORKSFORME
Severity:	major	CC:	orion
Priority:	P2
Version:	3.7.1p1
Hardware:	ix86
OS:	Linux

Description Andy Berkvist 2003-09-19 23:34:01 AEST

When logging into my servers via SSH, the /var/messages log shows the following
message after a successful ssh login:

'Nasty PTR Record "dublin.miser.priv" is set for 10.168.1.25, ignoring'

Now, this is the correct local domain and IP for my laptop, and I _can_ get into
the server, but it shouldn't be complaining.

The full extent of the problem became obvious this morning - one of my users
attempted to ssh from one server to another (something he does on a daily basis).

His attempts were rejected, and the following was in the logs of the 2nd server:
'userauth_hostbased mismatch: client sends stratus.miser.umass.edu, but we
resolve 128.119.162.230 to 128.119.162.230'.

Oops!  Instead of returning a name for the IP, it returns the IP again.  Not
going to make reverse lookups possible with that procedure.

I think the problem lies in canohost.c - line 97.  Possibly there's a bug in the
code.  When checking the man page for getaddrinfo(), I see two problems with it.
One is that the first argument should be "ntop" instead of "name" and the other
is that the second argument should probably be NULL and instead it's a pointer
to a string containing the digit zero.

In the meantime, things will work but one extra check (doing a forward lookup
on the name returned by a reverse lookup on the adddress of the client) will not
be done.

Comment 1 Damien Miller 2004-12-20 11:30:25 AEDT

I don't see any problems with the code: the second getaddrinfo call is supposed
to be called with 'name' and not 'ntop' - it is testing whether 'name' can be
parsed as is a numeric address (see the comment immediately above it). 

The use of a "0" for servname is consistent with other calls in OpenSSH - Itojun
explained it to me once a while ago, but I forget the rationale.

What does a reverse lookup using 'dig' show for the offending host?

Comment 2 Damien Miller 2005-07-04 11:33:54 AEST

seven months, no reply == no bug

Comment 3 Darren Tucker 2006-10-07 11:36:00 AEST

Change all RESOLVED bug to CLOSED with the exception of the ones fixed post-4.4.

Comment 4 Orion Poplawski 2017-10-07 07:40:53 AEDT

I ran into something like this just now with the switch to UseDNS to no.  Setting it back to yes allowed HostbasedAuthentication to work again.