Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


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

[BLU] ssh delays



David Kramer wrote:
| The only thing that comes to mind is I think SSH can be configured to do
| reverse DNS lookup in addition to the forward DNS lookup, and maybe
| there's a problem there.

Hmmm ...  I did some checking with nslookup on both ends of  a  link,
and  in  all  cases,  it  found  a name for the IP addresses within a
second. I also tried all the known host names with nslookup, and they
all got an address within a second.  This would seem to say that DNS,
forward and reverse, is working fine.

In this case, both ends do have at least two valid host names.  Could
that cause a problem for ssh?

I've verified with ping and traceroute that both ends find the  other
quickly, regardless of whether I use a FQDN or an IP address, and get
replies back within a second.

Something I haven't found in "man ssh":  ssh's  -v  option  obviously
only  applies  to the local end.  There doesn't seem to be any way to
get the remote end to explain what it's doing.  I'd think this  might
provide some clues if the remote end is having trouble validating the
stranger who's knocking on the door.  Is there a way to do this (that
works for a non-superuser)?

| > --
| > Notice: This message is copyright by the sender, and was doubly encrypted by
| > applying  the  Rot13 encryption algorithm twice.  Unauthorized decryption of
|                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| I like it!  Of course it takes a real geek to get the joke, but this is a
| good list for that.

Yeah, I figured most people would get it.  And, needless to say, all
members of the list are given permission to decrypt the message, and
to use it for your own purposes.

There is a lot of absurdity in the encryption debate; I'm just doing
my part to add to it ...

--
Notice: This message is copyright by the sender, and was doubly encrypted by
applying  the  Rot13 encryption algorithm twice.  Unauthorized decryption of
this message within the jurisdiction of US courts by anyone other  than  the
intended recipient(s) is a violation of the Digital Millenium Copyright Act,
and in punishable by five years in jail, a $500,000 fine, or or both.
-
Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at blu.org (Subject line is ignored).




BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org