Re: ssh_exchange_identification: Connection closed by remote host PART II
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? For example, if this were my LAN, bessie.blues matches
192.168.0.1. How/why would higher level domains be added? If the
reverse look-up went to the WAN, isn't the ~declared~ domain name
compared to the name registered to the IP?
If curiosity took too big a bite to cover with a Bandaid, no prob. I'll
get to the books soon enough.
>
>So if DNS is b0rked, questions about tcp wrappers don't apply,
>if you see what I mean.
Actually not, yet. ;~}
>
>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). Either way, I dislike the idea of defaulting to allow
rather than deny.
See above in re Bandaid. :)
--
gt
It is interesting to note that as one evil empire (generic) fell,
another Evil Empire (tm) began its nefarious rise. -- me
--
To UNSUBSCRIBE, email to debian-user-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: