VisualHostKey vs. RekeyLimit vs. VerifyHostKeyDNS

[Gerald Turner]

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.

* VerifyHostKeyDNS=yes

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

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

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.

-- 
Gerald Turner   Email: gturner at unzane.com   JID: gturner at unzane.com
GPG: 0xFA8CD6D5  21D9 B2E8 7FE7 F19E 5F7D  4D0C 3FA0 810F FA8C D6D5
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20140102/0c48aa5d/attachment.bin>