Re: SSH key algorithm updates

> On 07.11.2015, at 01:43, Peter Gutmann <[email protected]> wrote:
> 
> Max Horn <[email protected]> writes:
> 
>> That's the rub, I can't really (don't have access to any Windows machine).
> 
> 'strings ssh-app-name.exe'?  Since the identifiers are text strings, you don't
> really need to run the binary.

That's what I've been doing for multiple entries in my
list already; but it has limitation, e.g. if the binaries are wrapped in an
installer, which contains only a compressed version of the actual
executable. It also can lead to inaccurate results, and does not reveal
which methods are enabled/disabled by default, etc.

So in the end, initiating an actual connection seems like the best way to do
this.  But I also take information from user manuals, config files, or
direct info from vendors.

Anyway, I will try to get a VM with Windows up and running for this.  Of
course this doesn't help with other platforms I don't have access to,
such as Android, nor with solutions that don't offer any free downloads.


> 
>> One last question: Right now I only list these user auth methods:
> 
> 'none' is actually a bit of a problem since it's two different things, an auth
> mode and a mode-query-mechanism.  I support 'none' as a query mechanism since
> some clients don't work without it, but not as an auth mechanism, and I
> suspect a number of other implementions listed as supporting 'none' wouldn't
> actually let you in without a password either.  So perhaps this could be split
> into 'none-as-auth' and 'none-as-query'.  I'd certainly be nervous about using
> an implementation that had 'none-as-auth' enabled by default.

Yes, I was (and am) having precisely the same concern. But now I am
wondering whether I should just omit the "none" entry completely. After all,
it either leaves an incorrect bad impression (if people read it as meaning
that a server supports "non-as-auth" by default), and otherwise is useless,
as it doesn't tell you whether it actually means it works as "none-as-query".

Also note that to find out which it is, I can't rely on running "strings"
on an executable, and would need to rig a test setup...

I guess in the end it would be kind of cool if there was a big inter-op
test setup which tries to match tons of SSH implementations with each
other, and sees what actually works and what doesn't... But that
would a HUGE effort (I certainly don't have the resources for it).


Cheers,
Max