Re: strange SSH behavior

[Nick Holland <nick@holland-consulting.net>]

Ralph Forsythe wrote:
> 
> See this is the thing -- in my case it WAS because of failed reverse
> lookups (even though I turned that off).  And normally I'd be ok with
> that, except that the problem surfaced entirely on it's own accord, with
> no configuration changes on my part on the client PC, firewall (SSH host),
> or DNS server I was querying against.  Everything was fine without a
> reverse IP map to my 10.x.x.x system one day, the next this just started
> happening for no good reason.  And given that this SSH host has been
> running for months to this point with no issue, that pretty much rules out
> any DNS cache problems and what not.

FACT: If you do not have some kind of response to a reverse DNS query
of your workstation's IP, YOU WILL get a two minute delay when logging
in.  That has been true for a very long time, at least since 2.7, and
I'm fairly sure 2.6.  Your DNS resolution process has to either return
"something" or "error" (there are technical terms here, someone
pointed 'em out earlier in this thread), if it just doesn't respond,
you get these delays.
 
If you were NOT getting these delays before, your DNS resolution
process was returning "something" or "error" on a lookup of your
workstation ID.  That's the way it is.

If you are getting delays now, something changed...either your box's
config, your DNS server's response, or both.

> What also is growing more and more weird by the day are that multiple
> people are reporting this behavior all of a sudden, with the "It was
> working and now it's not" description.  It almost sounds like a software
> bug but then again I can't think of any reason why this issue would just
> suddenly surface.  

I think I can explain this...
(later)

> Putting my IP in /etc/hosts was a temp fix for my
> problem, but what happens when I switch my internal LAN to DHCP?  I have
> to make an entry for each possible address?  

yes.
I've done this using a simple program.  Mine was written in C, I would
suggest that a shell script would be far more logical to use. 8-)


Or, you can implement something so your DHCPd server updates an
internal DNS server.  As I have a relatively huge number of machines
in my house (21 responded to nmap, several aren't networked or don't
support TCP/IP), I went this route, and I am VERY glad I did.  There
are at least two ways to do this:  combine: 
   http://www.thismetalsky.org/magic/projects/dhcp_dns.html
with DJBDNS or I believe BIND 9 and an updated dhcpd can do this, as
well.  Before anyone is tempted to say it: we have heard all we need
to hear on the authors, the products, etc.  So, please refrain from
any comments along these lines.  Thank you.

> And it still doesn't explain
> why the problem surfaced to begin with...

Well, being I had some strange DNS issues lately, I spent some time
and figured out what was going on...

First of all, I am a cable modem user -- formerly with @Home, now with
Comcast.  My system went all to hell Saturday night, and Sunday, I
spent the morning figuring out what was going on.  

For the first time since I got cable, I have had to use DHCP on my
external interface.  dhclient-script, which is called by dhclient when
a new lease comes in.  One of the key things dhclient-script does is
to clobber whatever you had in /etc/resolv.conf and replace it with
info from the dhclient fetch.  When this took place, my gateway
machine no longer looked at my INTERNAL DNS server, but rather to the
cable company's server, which doesn't know squat about my network.

Another thing that happened last week was @Home was unplugged.  I
found at least two systems (so far) out in the field that I didn't
have easy access to the ISP's DNS server numbers (or in one case, was
given bogus numbers by the ISP), so I just punched in a publicly
accessible DNS server I knew of...which happened to be my @Home
numbers...  Guess what quit working last week?  (fortunately, these
were not problems the clients would notice...I am more careful on
stuff the client would be affected by...)

On top of that, it sounds like much of the Detroit area was down for a
while Saturday night, wasn't just me.  The replacement services for
@Home seem to be going through some adjustments and changes...one of
those changes may have been to have their DNS servers quit responding
to unregistered IPs...(remember, they don't want you running internal
networks).


In short, no, in spite of the fact that I experienced these same
problems over the last week -- in fact BECAUSE I experienced these
same problems, I am rather sure the issue is NOT a "mysterious bug in
OpenBSD", but rather a bunch of misconfigured computers which were not
showing their problem, and now, due to external changes, are.

Nick.
-- 
http://www.holland-consulting.net