Re: [ssh] Host key sync - "global-requests-ok" extension

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> [...] by only allowing -CTR, which they don't do, it's forcing them
> to fall back to things like FTP and (shudder) TFTP.

If the security properties of FTP are close enough suitable enough that
it's a fallback, then it seems to me that there is little value in
using ssh at all.

Because we have a really good hammer does not mean that all problems
are nails.

> [...], the server is saying "if you can't do -CTR, we'll force you to
> fall back to what's pretty much the least secure file transfer
> protocol there is (TFTP)".

Hardly.  A failed ssh connection does not force use of TFTP.  That is a
client-side choice, and I, at least, do not buy the argument that the
server is, by rejecting certain ciphers, forcing the client to do
anything, possibly excepting not use those ciphers.  If cipher
negotiation fails, client fallback is not within the ssh server's
control, nor is it any of the ssh server's business.

Also, the least secure file transfer protocol there is is probably
posting it to USENET. :-)

That said, I would prefer to see the CBC algorithms implemented, even
if disabled by default.  (I just checked my own implementation, and
I've now moved the CBC algorithms to (almost) the end of the preference
list.)

> The reason why my code warns about -CTR only servers is because I got
> tired of answering questions along the lines of "X works with Y, but
> not with OpenSSH, what's wrong?".

Ah, the joys of having users to support. :-/  Such a mixed blessing.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B