SSH login takes very long time...sometimes

[Lowell Gilbert]

Don't top-post, please.

James Tanis <jtanis at pycoder.org> writes:

> On 23 Dec 2005 09:30:56 -0500, Lowell Gilbert
> <freebsd-stable-local at be-well.ilk.org> wrote:
> > Marian Hettwer <MH at kernel32.de> writes:
> >
> > > Hej there,
> > >
> > > Kobi Shmueli wrote:
> > > > Try checking /etc/resolv.conf on oboe first, adding a static entry to
> > > > /etc/hosts of the remote ip/host should speed dns checks as well.
> > > > You can also run ssh in verbose mode (ssh -v oboe) or/and run sshd in debug
> > > > mode (sshd -d).
> > > >
> > > alternativly to check out wether it's dns related, you use set the
> > > Option "UseDNS no" in your sshd_config, so sshd won't try a reverse
> > > dns lookup.
> > > Give it a shoot. Usually ssh timeouts are related to DNS...
> >
> > That should be a last resort; the hostname checks are there for a
> > reason...

> What reason is that? A reverse-lookup is no longer really a valid way
> of filtering out the undesireable unless your lucky enough to be
> dealing only with those who have the knowledge and ability to control
> those entries.

[It doesn't filter anybody out; the DNS lookup will time out and the
user can log in anyway.]  What it does is helps you to know who you're
dealing with.  The fact that only the people who are *really*
responsible for the IP delegation can control the reverse entry is a
feature, not a bug.

>                Most residential ips either have no reverse-lookup or
> it's set to some long painful textual conglomeration devised by the
> isp (although at the isp I work at we will set it per some users
> requests..).

It doesn't matter *what* it is, just that there is one.  And remember
that you are not matching a forward mapping to a reverse one, but the
other way around.  It's fine if you use a host name that doesn't match
your reverse name mapping, as long as the reverse name mapping gives a
hostname that in turn points to you.

>              Anyway, to make a long story short, you end up locking
> out or at the very least delaying (for up to several minutes) the very
> people who use it. I can definately see the sysadmin side of it though
> were its used perhaps to remotely access a data center from a
> satellite location -- you don't much want or care that a residential
> ip has problems connecting to the server. It just definately doesn't
> seem to me a "last resort" option, at the drop of a hat someone can
> change their hostname to match their reverse dns and back again --

As I explained earlier, that's not the check that is being made.

> setting up a good packet filter to filter out all but the desired ip
> ranges seems a much more reliable method.

They are not exclusive.