VisualHostKey vs. RekeyLimit vs. VerifyHostKeyDNS

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

 



On Thu, 2 Jan 2014, Gerald Turner wrote:

> Hello list, I'm not sure whether this is bug worthy or just my own
> insanity.  I'm using 6.4p1 packages from Debian jessie and
> wheezy-backports.
> 
> I like VisualHostKey, although it may not add any protection (other than
> not trusting ones own known_hosts file?), I've become accustomed to it
> as it seems that extra neurons fire when I log into a host and get a
> visual cue of what looks like a strawberry or jester hat and suddenly a
> catalog of frequent commands relevant to the particular host surface in
> mind ;-)
> 
> I have two configuration problems that make VisualHostKey less usable.
> 
> * RekeyLimit
> 
> I'm no crypto expert, pretty much cargo-culting here, but from bits and
> pieces I've read, it seems like re-keying is crucial for a cipher like
> AES-GCM.  Maybe it's just a gut feeling inspired by strongSwan IPsec
> daemons which are constantly re-keying.
> 
> Every time the cipher is re-keyed, VisualHostKey clobbers the terminal,
> usually with broken line feeds such that the ascii-art is unintelligible
> and wraps off the right side of the terminal.  This is annoying,
> especially with a screen(1) full of ssh sessions that may be idle and
> re-keyed several times over a weekend, coming back and having to work
> through clearing the screens of each session (^L suffices for a shell or
> emacs, but sometimes the session is in a curses application, or lost
> information while tailing a log, etc.).  This gets uglier when making
> use of the fantastic ControlPersist options - seemingly logged out ssh
> session still blast the initial terminal with re-keying fingerprints.

Could you please file a bug for this on https://bugzilla.mindrot.org/ ?
We should suppress the message on rekeying.

> * VerifyHostKeyDNS=yes
> 
> It seems VerifyHostKeyDNS=yes short-circuits VisualHostKey - it's
> neither displayed on initial connection, or on re-keying (good).

If you really want to see it, maybe we could make a
VisualHostKey=always option?

> So I have a funny setup:
> 
>   For hosts which have SSHFP records, I have set VerifyHostKeyDNS=yes
>   and ineffectively set VisualHostKey=yes (never prints), and can also
>   set a timed RekeyLimit rate.
> 
>   For hosts which don't have SSHFP, I could leave RekeyLimit at the
>   default (1G none) and rarely see the re-key fingerprints, however in
>   an all-or-nothing sort of decision, simply set VisualHostKey=no and be
>   done with it.
> 
> Am I missing something?  Is there a way to comfortably get VisualHostKey
> back?  Perhaps a trivial/wishlist bug with re-keying should be filed?
> 
> Perhaps this is already solved by bug 2154, "Avoid key lookup overhead
> when re-keying":
> 
>   https://bugzilla.mindrot.org/show_bug.cgi?id=2154

Yes, it probably is.

> P.S. I think it's wonderful you folks are working on curve25519,
> ed25519, and chacha20+poly1305.  I've moved a bunch of systems to ECDHE
> last year, great speedup, especially from crap Atom clients, but feel
> that I've shot myself in the foot after Schneier's denouncement of the
> NIST curves.

IMO the concerns about the NIST EC curves are a bit overblown. If the NSA
had some way of breaking EC directly, then they wouldn't need to resort
to things like Dual_EC_DRBG.

-d



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

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux