See embedded responses...
>Date: Sat, 20 Jan 2001 19:59:02 -0500 (EST)
>From: Tom Diehl <[EMAIL PROTECTED]>
>Subject: Re: Fw: Could not reverse map address
>Sorry for the confusion. The 192.168 network has nothing to do with the
>problem. I use that at home. The problem is at work. Sooooooooo let me
>explain the problem again. On the work network ALL machines have real ip
>addresses. The nameserver is run by the ISP. The nameserver appears to
>be working properly (as far as I can tell so I could be wrong).
You can check this by running nslookup on the TO machine in question. Pick an
ip address in your local net, best would be one of the failing FROM machines
that is not logging into the TO machine:
nslookup 123.123.123.123
(where 123.123.123.123 is replaced with the chosen ip in local net above.)
If you don't get back a FQDN then you have a reverse DNS problem. Either it is
setup incorrectly locally (check /etc/resolv.conf in this case) or it is a
problem with the ISP (doubtful but possible if resolv.conf is OK).
If you think it is the ISP then you can further check by doing:
whois THE_DOMAIN.COM
where THE_DOMAIN.COM is the domain the ISP is hosting. On linux this will do a
recursive lookup of the domain in internic's whois server and then the actual
domain registrar's whois DB (at least my whois under RH 7.0 does recursion
automatically). If it doesn't do the lookup recursively, then run whois again
with THE_DOMAIN.COM@WHOIS_SERVER (found in output of first whois query).
Look at the output for 'Domain servers in listed order' at the end of the
output. Now do the DNS tests above once for each server by adding the first and
second ip addresses to the nslookup command.
nslookup 123.123.123.123 12.12.12.12
where 12.12.12.12 is replaced for each DNS server ip address found with whois
above.
If this fails on one or both, then the DNS hosting people (the ISP) have a
munged database or weren't told about changes, etc. I'd try several to see if
it was just an omission for that one client before telling the ISP the DNS
server is munged. Supplying the info you gathered with whois/nslookup will help
and generally get a better response from the ISP.
Further tests would be to take what you know the real FQDN to be and run
nslookup as above and see if you can track it down this way. Thus, if you chose
ip address 123.123.123.123 and it had a FQDN of client.THE_DOMAIN.COM, then an
nslookup on the name client.THE_DOMAIN.COM should give 123.123.123.123.
One thing that SSH 1.2.30 does is do reverse mappings of ip address and remote
name. Thus, the nslookups above need to be equal, that is:
nslookup FQDN <=> nslookup ip_address
this is done to catch possible security problems. Since it uses gethostbyname
then it will follow the settings of nsswitch.conf to find where to look,
file/dns/nis/etc.
> When I
>ssh from one machine on the work net to another machine on the work net
>if the machine I am sshing FROM is NOT in /etc/hosts on the TO machine
>the machine I am sshing TO complains that the reverse name lookup is
>failing (I do not have the exact error in front of me. I can get it if
>needed). In addition if I use the same 2 machines and telnet in, telnet
>closes the connection with no errors. If I put the from machine in the
>to machine's hosts file all is well. Since this is causing problems with
>both ssh and telnet I suspect this is some kind of DNS weirdness but I
>do not know how to prove it.
Now that all of the above was said, it sounds like your Linux box has a wildcard
entry in /etc/hosts.allow. In fact, possibly a domain wildcard like:
ALL: .YOUR_DOMAIN.COM
One thing to try is adding a different wildcard:
ALL: 204...
where the 204... is the common part of all ip addresses on your network.
Assuming you have a class c and all machines start 204.100.1 then add:
ALL: 204.100.1.
to /etc/hosts.allow.
This should then allow both telnet and ssh to work, maybe even bypassing the
reverse DNS lookup that is causing you problems. Well, I looked at the source
and it always does a gethostbyaddr and gethostbyname on all client connections.
Thus, you can speed it up by adding 'hosts: file' or 'hosts: file
[NOTFOUND=return] dns', as Don previously sent info about.
(You can also try entering just the full ip address in hosts.allow for the
client FROM host to see what that gives you.)
If it now works for telnet and not ssh, then look in sshd_config for AllowHosts
and DenyHosts lines and change these to ip addresses like in /etc/hosts.allow.
Well, I hope this gets you further than before.
--Dave
--
David Knight French
Black Mountain Computer Consulting
Voice: (858)279-4862
Email: [EMAIL PROTECTED]
