[ILUG] sshd problem

[Gavin McCullagh]

On Mon, 19 Apr 2004, Lee Hosty wrote:

> On Mon, 19 Apr 2004, Lee Hosty wrote:
> 
> > > You should also be looking in /var/log/auth.log to see if you can see
> >
> > ah. yes. found the problem, I think:
> >
> > Apr 19 17:47:30 helium sshd[623]: warning: /etc/hosts.allow, line 16:
> > can't verify hostname:
> > gethostbyname(rfc1918.space.should.not.be.used.on.publicips) failed
> > Apr 19 17:47:30 helium sshd[623]: refused connect from 192.168.0.6

I came across pretty much this problem only the other day on a friends home
lan.  It's a DNS one if I'm not mistaken.  You have 192.168 addresses in
your house (which is perfectly reasonable of course).  If you ask a public
DNS server for the name of a 192.168 address, you'll likely get back the
answer

rfc1918.space.should.not.be.used.on.publicips

hence part of the above strange message.

> As it happens, it was /etc/hosts that was the problem, along with extra
> computers on the WAN - with all except the knoppix box using DHCP.

If you look in the comments on a standard debian /etc/hosts.deny you'll see 

# The PARANOID wildcard matches any host whose name does not match its
# address. 

So, ALL:PARANOID in deny means it denies any whose name & ip can't be
matched up by DNS, hosts file, etc.

> Is there a standard method of dealing with this? A wildcard in
> /etc/hosts.allow I would presume?

Either:

1) your client thinks it has the name
"rfc1918.space.should.not.be.used.on.publicips".  If it were given an IP
and DNS but no hostname, it might ask the DNS for it's own name and get
that back. 
2) your server is doing a DNS lookup of 192.168.0.6 and getting back the
"rfc....".

I reckon it's [1].  The solution is to set the hostname on your client.

If it's [2] placing a line like one of the below in /etc/hosts should sort
it out as it'll be able to then resolve name & ip address using the hosts
file and won't revert to DNS for the answer.

192.168.0.6  [clienthostname].[yourlocaldomain] [clienthostname]
192.168.0.6  [clienthostname]

You could alternatively setup an in-house DNS with something like dnsmasq
or pdnsd which would act as a proxy to your outside world DNS and resolve
the internal stuff too but that might be a little heavy in this instance.
It would solve either problem though.

Gavin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mail.linux.ie/pipermail/ilug/attachments/20040420/d040dfda/attachment.pgp