Re: Interop lsh and SSH-2.0-GitLab-SSHD

>> This isn't that much of a mystery.  In the words of 4252,
> That always seemed a bit contrived to me, I couldn't imagine a client
> having a smorgasbord of keys to play with and trying each in turn,
> "Will this one do? No? OK, how about this then?",

Well, that's exactly what I typically do have.  I have three keys in my
agent and one on disk (actually, 19 on disk, but most of them are under
names the client doesn't know to look at).

> in the same way that you don't connect to the server and keep running
> through passwords until you find one that fits.

It wouldn't be too unreasonable to put the onus on the client, or the
client's user, to keep track of which key to use with which server.
But it is a significant increase in convenience to not need that.

I can see three respects in which the analogy to passwords is invalid:

* I don't reuse passwords across multiple servers.  (Most of the
reasons for that don't apply to ssh identities.)

* It is difficult to mechanically tell whether a password is accepted.
(Assuming non-ssh, here, something a la telnet.)

* Trying a wrong password leaks the password to the server.

If it weren't for those, mechanically trying each password in turn
would not be that silly an idea.

> Just out of curiosity, what are you using that takes seconds to
> generate a sig?

Well, strictly, takes seconds to perform an ssh authentication.  That's
more than signature generation, but not much more; to a pretty good
approximation, all the time goes to doing p = b^e mod m.

The host in question is a SPARCstation-20 with

cpu0 at mainbus0: RT620/625 @ 125 MHz, on-chip FPU
cpu0: 256K byte write-back, 64 bytes/line, sw flush: cache enabled

Perhaps I'm just doing something relatively inefficient.  I do have
slower machines around, but not in routine use.

I just did a test:

sparkle% date; ssh stone -no-share date; date
Thu Oct 26 23:42:39 EDT 2023
Thu Oct 26 23:43:09 EDT 2023
Thu Oct 26 23:43:10 EDT 2023
sparkle% 

About thirty seconds, almost all of which goes for kex and auth.
(Sparkle is an SS20.  Stone is a _much_ faster machine, a Xeon X3220 at
2.40GHz; when talking with sparkle, stone can be considered infinitely
fast for practical purposes.  In another test, between the same two
hosts, it was 27 seconds.  Watching the clock on my screen and the
agent report of when PK operations were requested, 18 seconds for kex
and 9 for auth.)

> The slowest thing I work with would be around an 80MHz M4 and I'm
> pretty sure that doesn't take that long for it.

M4?  Don't know that.

Perhaps I'm using larger keys than you are.  Almost all my keys are
3072-bit.  (One of the downsides of having fast machines in others'
hands is that it means decent security requires significantly more
computation from slow machines.)

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email protected]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B