Subject: Re: SSH key algorithm updates

From: Max Horn <[email-masked]>
Date: Fri, 6 Nov 2015 19:49:55 +0100

Hi denis,

> On 06.11.2015, at 18:59, denis bider <[email-masked]> wrote:
> 
> > Also, of course there are implementations missing (one notable
> > is Bitvise's; I started work on that, but had a hard time finding
> > reliable a source for what they actually support and what not).
> 
> If you can run a Windows executable,

That's the rub, I can't really (don't have access to any Windows machine). Though I'll try whether wine can do it. I'll try to setup a Windows VM for  this one of these days.

> 
> Both the client and the server are free for use that is both personal and non-commercial. The client goes further than that, and is also free for individual use in organizations.
> 
> The following is what a default SSH Server installation (latest version 6.43) supports and enables at the moment. All algorithms listed are supported. Only the "true" ones are enabled by default:

OK, that more or less matches what I had "guessed" based on FlowSSH (which already was on my page).
Though I do not yet have a way to show on the page when an algorithm is supported but disabled by default. This is on my TODO list, though. Amongst other things (e.g. "supported since version x.y" would be nice to have, too)

[...]

> Algorithms supported by our client mirror those in the server.

OK, so for now I'll keep a single entry for the two.

Thanks for your help, I now added Bitwise SSH to my page.

One last question: Right now I only list these user auth methods:

    userauth:   # the following is a guess, based on what FlowSsh supports
        - publickey
        - password
        - keyboard-interactive
        - none

But since you mention gss in your kex list, I am wondering whether this is incomplete...?

Cheers,
Max

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 7 Nov 2015 00:43:43 +0000

Max Horn <[email-masked]> 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.

>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.

Peter.

---

From: denis bider <[email-masked]>
Date: Fri, 6 Nov 2015 17:59:00 +0000

> reliable a source for what they actually support and what not).

If you can run a Windows executable, you can simply download our stuff from our website:

https://www.bitvise.com/

The following is what a default SSH Server installation (latest version 6.43) supports and enables at the moment. All algorithms listed are supported. Only the "true" ones are enabled by default:

> q algs.*
With kex {
  ecdhSecp256k1 true
  ecdhNistp256 true
  ecdhNistp384 true
  ecdhNistp521 true
  dhGexSha256 true
  dhGexSha1 true
  dhG1Sha1 false
  dhG14Sha1 true
  gssG1Sha1Krb5 false
  gssG14Sha1Krb5 true
  gssGexSha1Krb5 true
}
With encr {
  aes256-ctr true
  aes192-ctr true
  aes128-ctr true
  3des-ctr true
  aes256-cbc false
  aes192-cbc false
  aes128-cbc false
  3des-cbc false
  none false
}
With mac {
  hmac-sha2-256 true
  hmac-sha1 true
  hmac-md5 false
  hmac-sha2-256-96 false
  hmac-sha1-96 false
  hmac-md5-96 false
  none false
}
With cmpr {
  zlib true
  none true
  delayCompression false
}

Supported host key algorithms are:

ssh-rsa
ssh-dss
ecdsa-sha2 over secp256k1
ecdsa-sha2 over nistp256
ecdsa-sha2 over nistp384
ecdsa-sha2 over nistp521

denis

----- Original Message -----
From: Max Horn 
Sent: Friday, November 6, 2015 03:08
To: [email-masked] 
Cc: Mark D. Baushke 
Subject: Re: SSH key algorithm updates

Hi there,

just joined the list, but saw on the list archive that a few days ago,
Mark D. Baushke wrote on this thread:

> It would be useful to see what other protocols various SSH implementers
> have been adding and see if there is a desire to move any of them into a
> recommended or optional standard.

As a matter of fact, I started such a page some time ago:

  http://ssh-comparison.quendi.de/
  http://ssh-comparison.quendi.de/comparison.html

I tried my best to make it accurate, but of course cannot exclude mistakes.
Also, of course there are implementations missing (one notable is Bitvise's;
I started work on that, but had a hard time finding reliable a source for
what they actually support and what not).

Anyway, issue reports and pull request (also with info on additional
implementations) are most welcome:

  https://github.com/fingolfin/ssh-comparison

The comparison page shows for example that hmac-sha2-256 and hmac-sha2-512
support is quite good now; one notable SSH library not implementing it yet
in a released version is libssh2, but they will have it in the next release
(the code is in their repository already), which in turn should allow
various clients based on it to support it. Another exception is lsh.

Cheers,
max

---

From: Max Horn <[email-masked]>
Date: Sat, 7 Nov 2015 10:51:59 +0100

> On 07.11.2015, at 01:43, Peter Gutmann <[email-masked]> wrote:
> 

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.

> 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

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 8 Nov 2015 03:06:50 +0000

Max Horn <[email-masked]> writes:

>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. 

There are a bunch of universal extractors that will bypass the need to
install, google "windows installer unpacker", so you don't need to install
random binaries on your system.

>It also can lead to inaccurate results, and does not reveal which methods are
>enabled/disabled by default, etc.

Yeah, that's a good point.  OTOH you then need to do test runs on the app to
try and probe what's present and what isn't.  It depends on how much time you
want to sink into it :-).

>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".

That sounds like a good idea.  You more or less have to support none-as-query
in order to be able to communicate with some clients, so in theory every
implementation would have to have support for "none".  OTOH I would imagine
few implementations allow you in without authentication, so few would suport
the other "none".

Oh, and you'll need to add columns for the SHA-2 forms of signatures soon :-).

Peter.

---

From: denis bider <[email-masked]>
Date: Sun, 8 Nov 2015 03:35:02 +0000

A universal extractor might have trouble with our stuff. We don't use Windows Installer (the thing is a nightmare), instead we pack a large BLOB with all the files, compress it with a compression library, and stuff the compressed BLOB as a resource into the installer executable.

If the extractor is universal enough to recognize the compressed resource, and its compression format, that would leave you with a BLOB containing all the files, on which you could run "strings". You're going to get loads of strings, however.

I agree that including the "none" user auth method should probably not be done, since it's usually supported as discovery rather than an authentication method, and it's hard to tell when it's supported for login (if ever).

Peter Gutmann <[email-masked]> , 11/8/2015 3:06 AM:

Peter.