[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ssh_exchange_identification: Connection closed by remote host PART II



* Gary Turner (kk5st@swbell.net) spake thusly:
> On Sun, 24 Mar 2002 18:29:39 -0600, Dimitri Maziuk wrote:
> 
> >* Gary Turner (kk5st@swbell.net) spake thusly:
> >> On Sun, 24 Mar 2002 13:12:56 -0600, Dimitri Maziuk wrote:
> 
> >> >Didn't you read Sven's rely? It says "DNS problem" right there.
> >Make that "reply".
> 
> Hmph; I see so many typos on the lists, I don't even see my own any
> more. <|:-(
> 
> >> >
> >> Yes, I did.  Didn't you read mine?
> >> "If this is not germane to the thread, I apologize.  If it is wrong, I
> >> seek instruction."
> >
> >Well, it's relevant as most tcp apps rely on DNS for hostname 
> >resolution. It's not particular to ssh or tcp wrappers, though.
> >
> >DNS configuration, OTOH, is too big a topic for a quick instruction
> >in an email reply. There are books and howtos on the subject.
> 
> OK, thanks.  I put the neo in phyte and am building my system task at a
> time.  DNS and SSH are dishes I'm not ready to wash just yet. :)
> 
> >Just to give you a concrete example: assume 192.168.1.0 subnet.
> >Missing a trailing dot in RDNS zone, like this: 
> >1 IN PTR host.foo.bar
> > dot missing here ---^
> >will result in reverse lookup for 192.168.1.1 returning something
> >like "host.foo.bar.in-addr.arpa". That will not match "*.foo.bar"
> >entry in hosts.allow, nor the entry in ssh's known hosts file.
> 
> Curiosity just bit me in the butt.  Where does the .in-addr.arpa come
> from?  

>From the way bind works. See e.g. O'Reilly's "DNS and Bind".

> >So if DNS is b0rked, questions about tcp wrappers don't apply,
> >if you see what I mean.
> 
> Actually not, yet. ;~}

If your DNS is b0rked, access control is b0rked, too. Regardless
of whether your hosts.access files are correct.

> >The really interesting question is whether relying on something
> >as notoriously unreliable as DNS for access control is a sane 
> >idea.
> 
> Vagrant thought:  Either hosts.access is not the appropriate tool in
> this case, or the reverse look-up does not use it properly (from hosts.*
> point of view).

It's host.access that uses DNS lookups, not the other way around.
It works most of the time and gives you another layer of access
control (defence in depth). It's just that between misconfigured
servers, DNS spoofing, etc., it's a wonder it works at all.

Dima
-- 
Tlaloc: What was Elrond's second name?
Gruber: Hubbard                           -- <ahbou=3C69EB63.A7C431F4@last.com>


-- 
To UNSUBSCRIBE, email to debian-user-request@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org



Reply to: