Debian Bug report logs - #774711
OpenSSH should use stronger crypto algo and parameters respectively disable others

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Vasil Kolev <vasil@ludost.net>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: openssh: OpenSSH should have stronger ciphers selected at least on the server side.

Date: Tue, 06 Jan 2015 18:52:55 +0200

Source: openssh
Severity: wishlist

Dear Maintainer,

As per a talk at 31C3 ("Reconstructing narratives"[1]), which mentions that there
are possible decrypts/attacks on OpenSSH, and a document which contains some
best practices in that regard[2] that got published afterward, is it possible to:

- get openssh to generate 4096-bit RSA keys by default;
- increase the size of the DH modulus to 4096;
- disable old ciphers, like the 3DES based ones.

I understand that there is nothing sure and final, but most of these recommendations
seem like a good idea from a security point of view, and won't break compatibility
except with some very old (and maybe insecure) clients. For such compatibility
issues, a warning might be provided with an explanation how to re-enable them,
or a way to enable a "hardened" configuration.


1. http://media.ccc.de/browse/congress/2014/31c3_-_6258_-_en_-_saal_1_-_201412282030_-_reconstructing_narratives_-_jacob_-_laura_poitras.html
2. https://stribika.github.io/2015/01/04/secure-secure-shell.html

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
     ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: 8.0
  APT prefers testing
  APT policy: (1120, 'testing'), (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=bg_BG.UTF8, LC_CTYPE=bg_BG.UTF8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Message #10 received at 774711@bugs.debian.org (full text, mbox, reply):

From: Christoph Anton Mitterer <calestyo@scientia.net>

To: 774711@bugs.debian.org

Cc: 774711-subscribe@bugs.debian.org

Subject: Re: Bug#774711: openssh: OpenSSH should have stronger ciphers selected at least on the server side.

Date: Tue, 06 Jan 2015 18:17:44 +0100

[Message part 1 (text/plain, inline)]

On Tue, 2015-01-06 at 18:52 +0200, Vasil Kolev wrote: 
> - get openssh to generate 4096-bit RSA keys by default;
... and disable DSA and RSA1 keys, which is possible if you name all
other "default" key explicitly in the config, like:
sshd_config: 
HostKey                 /etc/ssh/ssh_host_ed25519_key
HostKey                 /etc/ssh/ssh_host_ecdsa_key
HostKey                 /etc/ssh/ssh_host_rsa_key
#Note: SSH Version 2 DSA host keys are implicitly disabled.
##HostKey               /etc/ssh/ssh_host_dsa_key
#Note: SSH Version 1 RSA host keys are implicitly disabled.
##HostKey               /etc/ssh/ssh_host_key

ssh_config: 
IdentityFile            ~/.ssh/id_ed25519
IdentityFile            ~/.ssh/id_ecdsa
IdentityFile            ~/.ssh/id_rsa
#Note: SSH Version 2 DSA identities are implicitly disabled.
#IdentityFile           ~/.ssh/id_dsa
#Note: SSH Version 1 RSA identities are implicitly disabled.
#IdentityFile           ~/.ssh/identity


> - increase the size of the DH modulus to 4096;
That only makes really sense if diffie-hellman-group1-sha1 and
diffie-hellman-group14-sha1 are disabled (which they should be anyway),
since these have fixed size groups of 1024 and 2048 bits.

For DH-GEX, one can easily allow only more secure groups, simply by
removing all smaller ones from /etc/ssh/moduli
This unfortunately works only for the server side.
For the client side OpenSSH has a hard coded min/preferred/max DH group
size, with too low min, and too low max.
See:
https://bugzilla.mindrot.org/show_bug.cgi?id=2303

Also note, if you completely empty /etc/ssh/moduli, the DH-GEX will
again fall back to some hardcoded 2048bit only DH group:
https://bugzilla.mindrot.org/show_bug.cgi?id=2302

And perhaps see also:
https://bugzilla.redhat.com/show_bug.cgi?id=1010607
https://bugzilla.redhat.com/show_bug.cgi?id=1062925


> - disable old ciphers, like the 3DES based ones.
Yeah... IMHO the preferred algo defaults (with respect to security, not
interoperability with old systems) should be (as of version 6.7): 
HostKeyAlgorithms       ssh-ed25519,ssh-ed25519-cert-v01@openssh.com,ecdsa-sha2-nistp521,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp384,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp256-cert-v01@openssh.com,ssh-rsa,ssh-rsa-cert-v01@openssh.com
KexAlgorithms           curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256
Ciphers                 chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs                    hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com

with HostKeyAlgorithms of course only for ssh_config,... and one might
want to remove all nist curves, since they're... questionable.


> I understand that there is nothing sure and final, but most of these recommendations
> seem like a good idea from a security point of view, and won't break compatibility
> except with some very old (and maybe insecure) clients.
Unfortunately Debian usually rather goes the way less secure for
everyone, just to please some oldish systems whose admins haven't done
their homework,


>  For such compatibility
> issues, a warning might be provided with an explanation how to re-enable them,
> or a way to enable a "hardened" configuration.
I've recently created hardened versions for sshd_config and
ssh_config... I could publish them here, but I doubt that this would be
merged.

Cheers,
Chris.

[smime.p7s (application/x-pkcs7-signature, attachment)]

Message #15 received at 774711@bugs.debian.org (full text, mbox, reply):

From: Matthew Vernon <matthew@debian.org>

To: Christoph Anton Mitterer <calestyo@scientia.net>, 774711@bugs.debian.org

Subject: Re: Bug#774711: openssh: OpenSSH should have stronger ciphers selected at least on the server side.

Date: 07 Jan 2015 15:25:35 +0000

Christoph Anton Mitterer <calestyo@scientia.net> writes:

> On Tue, 2015-01-06 at 18:52 +0200, Vasil Kolev wrote: 
> > - get openssh to generate 4096-bit RSA keys by default;
> ... and disable DSA and RSA1 keys, which is possible if you name all
> other "default" key explicitly in the config, like:
> sshd_config: 
> HostKey                 /etc/ssh/ssh_host_ed25519_key
> HostKey                 /etc/ssh/ssh_host_ecdsa_key
> HostKey                 /etc/ssh/ssh_host_rsa_key
> #Note: SSH Version 2 DSA host keys are implicitly disabled.
> ##HostKey               /etc/ssh/ssh_host_dsa_key
> #Note: SSH Version 1 RSA host keys are implicitly disabled.
> ##HostKey               /etc/ssh/ssh_host_key

The problem with this approach is that you won't get any new keys onto
your system in future openSSH versions that support them. So if we did
this in Debian, then everyone would have to remember to update that
list themselves on subsequent upgrades. 

And, we'd rather use upstream config where possible, I think.

Regards,

Matthew 

-- 
"At least you know where you are with Microsoft."
"True. I just wish I'd brought a paddle."
http://www.debian.org

Message #26 received at 774711@bugs.debian.org (full text, mbox, reply):

From: Christoph Anton Mitterer <calestyo@scientia.net>

To: Matthew Vernon <matthew@debian.org>

Cc: 774711@bugs.debian.org

Subject: Re: Bug#774711: openssh: OpenSSH should have stronger ciphers selected at least on the server side.

Date: Wed, 07 Jan 2015 19:42:30 +0100

[Message part 1 (text/plain, inline)]

On Wed, 2015-01-07 at 15:25 +0000, Matthew Vernon wrote: 
> Christoph Anton Mitterer <calestyo@scientia.net> writes:
> 
> > On Tue, 2015-01-06 at 18:52 +0200, Vasil Kolev wrote: 
> > > - get openssh to generate 4096-bit RSA keys by default;
> > ... and disable DSA and RSA1 keys, which is possible if you name all
> > other "default" key explicitly in the config, like:
> > sshd_config: 
> > HostKey                 /etc/ssh/ssh_host_ed25519_key
> > HostKey                 /etc/ssh/ssh_host_ecdsa_key
> > HostKey                 /etc/ssh/ssh_host_rsa_key
> > #Note: SSH Version 2 DSA host keys are implicitly disabled.
> > ##HostKey               /etc/ssh/ssh_host_dsa_key
> > #Note: SSH Version 1 RSA host keys are implicitly disabled.
> > ##HostKey               /etc/ssh/ssh_host_key
> 
> The problem with this approach is that you won't get any new keys onto
> your system in future openSSH versions that support them. So if we did
> this in Debian, then everyone would have to remember to update that
> list themselves on subsequent upgrades.
Sure... I definitely wouldn't want to touch existing configs
automatically (unless they're equal to Debian's default config).


Apart from that, people should probably start to learn that SSH is a
complex service just like httpd or anything else,... and that for
properly maintaining it is not enough to install upgrades without
looking at the changelogs, configs, etc.
So I think that this "everyone would have to remember that..." should
anyway be the case:
- either upstream chooses to always change to hardened defaults
  => than people need to look at their stuff, because they might need to
     manually enable less secure things for interoperability with older
     clients/servers
- or upstream doesn't choose hardened defaults
  => then people should need to look at their stuff because less secure
     or insecure may be allowed
What ever you do.. people have a duty to properly maintain their
stuff,... even for "simple" things like SSH.

And in general I prefer that things are secure per default, and only
those people have to suffer which don't do their homework.


> And, we'd rather use upstream config where possible, I think.
Sure, as I mention in in #74793)...but what if they don't?


Cheers,
Chris.

[smime.p7s (application/x-pkcs7-signature, attachment)]

Message #33 received at 774711@bugs.debian.org (full text, mbox, reply):

From: Christoph Anton Mitterer <calestyo@scientia.net>

To: 774711@bugs.debian.org

Cc: control@bugs.debian.org

Subject: Re: openssh: OpenSSH should have stronger ciphers selected at least on the server side.

Date: Wed, 07 Jan 2015 21:58:28 +0100

[Message part 1 (text/plain, inline)]

retitle 774711 OpenSSH should use stronger crypto algo and parameters respectively disable others
stop

Hi.

First, I've modified the title, since I think it's useless to only
harden servers while clients would be left at "less secure" defaults.
Also, the title "should have stronger ciphers selected" was kinda
misleading, since stronger ciphers were actually selected - the problem
was rather that "weaker" ones are still allowed as well.


Then, FYI, I posted information about these two bugs on the
openssh-unix-dev mailing list.


Cheers,
Chris.


[0] https://lists.mindrot.org/pipermail/openssh-unix-dev/2015-January/033297.html

[smime.p7s (application/x-pkcs7-signature, attachment)]

Message #40 received at 774711@bugs.debian.org (full text, mbox, reply):

From: Jens Thiele <karme@karme.de>

To: 774711@bugs.debian.org

Subject: Re: Bug#774711: openssh: OpenSSH should have stronger ciphers selected at least on the server side.

Date: Thu, 21 May 2015 10:30:38 +0200

see also:
https://www.weakdh.org/
The Logjam Attack
https://www.weakdh.org/imperfect-forward-secrecy.pdf
"
Is NSA Breaking 1024-bit DH?

Our calculations suggest that it is plausibly within NSA’s resources to
have performed number field sieve precomputations for at least a small
number of 1024-bit Diffie-Hellman groups. This would allow them to break
any key exchanges made with those groups in close to real time.
"

Message #45 received at 774711@bugs.debian.org (full text, mbox, reply):

From: Matthew Vernon <matthew@debian.org>

To: 774711@bugs.debian.org

Subject: Re: Bug#774711: openssh: OpenSSH should have stronger ciphers selected at least on the server side.

Date: 21 May 2015 13:59:36 +0100

Jens Thiele <karme@karme.de> writes:

> see also:
> https://www.weakdh.org/

A few thoughts (my colleage David McBride was helpful here):

i) plausibly-new openssh (>=5.7) support and prefer ECDH, which I
believe to be unaffected by this issue. The commonest Windows client
(PuTTY), however, doesn't support this yet.

ii) I think it would be sensible to remove weaker moduli from
/etc/ssh/moduli. The current size distribution:
bits  count
1023  36
1535  32
2047  28
3071  26
4095  31
6143  20
8191   6

A colleague reports that generating new 2047-bit moduli takes a few
minutes, and that time taking scales non-linearly with length (~90
minutes for 4095, ~40 hours for 8191). So I'm not sure if we should
make some newer larger moduli and start shipping them, and/or start
generating some at install time; the latter feels too invasive to me. 

iii) it's less clear what to do about the weaker KexAlgorithms -
diffie-hellman-group1-sha1 uses Oakley Group 2 (1024 bits) and
diffie-hellman-group14-sha1 uses Oakley Group 14 (2048 bits); RFC4253
says that implementations MUST support these, and I don't know what
clients might break if we were to stop doing so.

I'd be interested to hear the opinions of the other openssh
maintainers, and perhaps we should ask upstream for their views (I've
not seen anything on the upstream dev list as yet).

Regards,

Matthew

-- 
"At least you know where you are with Microsoft."
"True. I just wish I'd brought a paddle."
http://www.debian.org

Message #50 received at 774711@bugs.debian.org (full text, mbox, reply):

From: Christoph Anton Mitterer <calestyo@scientia.net>

To: Matthew Vernon <matthew@debian.org>, 774711@bugs.debian.org

Subject: Re: Bug#774711: openssh: OpenSSH should have stronger ciphers selected at least on the server side.

Date: Thu, 21 May 2015 17:58:54 +0200

[Message part 1 (text/plain, inline)]

On Thu, 2015-05-21 at 13:59 +0100, Matthew Vernon wrote: 
> bits  count
> 1023  36
> 1535  32
I'd remove at least these completely.

> 2047  28
This I'd keep probably only with a warning (according to ECRYPT II it's
only safe in the range to aat best 2020-2030

> 3071  26
Still below "Long term protection", according to ECRYPT II

> 4095  31
> 6143  20
> 8191   6
More of these!


> A colleague reports that generating new 2047-bit moduli takes a few
> minutes, and that time taking scales non-linearly with length (~90
> minutes for 4095, ~40 hours for 8191). So I'm not sure if we should
> make some newer larger moduli and start shipping them, and/or start
> generating some at install time; the latter feels too invasive to me. 
It shouldn't be a problem if the groups are pre-competed (and thus known
to the attacker).


> iii) it's less clear what to do about the weaker KexAlgorithms -
> diffie-hellman-group1-sha1 uses Oakley Group 2 (1024 bits) and
> diffie-hellman-group14-sha1 uses Oakley Group 14 (2048 bits); RFC4253
> says that implementations MUST support these, and I don't know what
> clients might break if we were to stop doing so.
They should be kept in the client/server, but disabled per default (not
via patching the hardcoded defaults, but via a custom ssh[d]_config
file).

Or even better, they should be disabled upstream per default and
enabling them should be only possible when e.g. specifying some
"--allow-unsafe-algos" parameter as option to ssh[d].


> I'd be interested to hear the opinions of the other openssh
> maintainers, and perhaps we should ask upstream for their views (I've
> not seen anything on the upstream dev list as yet).
I've did that some months ago and as mentioned before I've even opened
bug reports about the related issues,... but there seems to be little
willingness to work on this issue.

Apparently focus is more on CSH (having a _C_ompatbile SH) than SSH
(having a _S_ecure SH)... but that seems to match Debian's security
philosophy quite well =)


Cheers,
Chris.

[smime.p7s (application/x-pkcs7-signature, attachment)]

Message #55 received at 774711@bugs.debian.org (full text, mbox, reply):

From: Matt Taggart <taggart@debian.org>

To: debian-ssh@lists.debian.org

Cc: taggart@debian.org, 774711@bugs.debian.org

Subject: Re: ssh backports

Date: Wed, 26 Aug 2015 15:50:41 -0700

Matt Taggart writes....

> On a related note, is there any plan for deprecating old
> KexAlgorithms/Ciphers/MACs in order to prevent downgrade attacks?
> I know this is tricky, but surely we can start removing really old
> and weak stuff from the default lists? (even if it's still enabled
> so admins can enable for special cases). I can file a wishlist bug
> for this if you think it's a good idea.

After I wrote this I discovered that #774711 has a lot of good
discussion
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774711

Also someone pointed out what I wrote is confusing, so I will
elaborate...

The ssh_config(5) manpage lists for KexAlgorithms, Ciphers, and
MACs the default values that will be tried and the order in which
they are tried. These appear to be defined in myproposal.h (lots of
ifdefs so it varies depending on what you have enabled when building).

I am proposing leaving support for older and known weaker things
enabled, but removing them from the default list of things that will
be tried. That way if a user needed to talk to a system that could
only use older settings, they should still enable them in their
config, ideally in a 'Host' stanza specific to only the servers they
actually needed them for. (For example squeeze and older systems,
embedded "appliances" with older ssh versions, etc).

As for which should be dropped from the default search order, I will
defer to the experts. In addition to the discussion in #774711, this
page is good

https://stribika.github.io/2015/01/04/secure-secure-shell.html

More secure by default, but doesn't prevent communication if you are
required to use weaker things (and users can still choose to make
their defaults not use the weaker things at all).

Hopefully that makes more sense.

Thanks,

-- 
Matt Taggart
taggart@debian.org

Message #60 received at 774711@bugs.debian.org (full text, mbox, reply):

From: Matt Taggart <taggart@debian.org>

To: 774711@bugs.debian.org

Cc: taggart@debian.org

Subject: tables of debian openssh crypto features

Date: Thu, 10 Sep 2015 16:19:21 -0700

I was interested in what crypto features the ssh in each Debian release 
supported, to see what disabling some would mean, so I gathered the info. 
Let me know if you see any errors.

Current versions of openssh as of Sept 10, 2015:

| squeeze-lts | 1:5.5p1-6+squeeze6 |
|    wheezy   |  1:6.0p1-4+deb7u2  |
|    jessie   |      1:6.7p1-5     |
|   stretch   |      1:6.9p1-1     |
|     sid     |      1:6.9p1-2     |

Tables of crypto features that the openssh in each release of Debian 
supports. Gathered with ssh -Q(jessie and newer), ssh_config(5) and 
source(wheezy and squeeze). (These will look better with a fixed width font)

Key types
| sq | wh | je | st | si | type                                     |
=====================================================================
| X  | X  | X  | X  | X  | ssh-rsa                                  |
| X  | X  | X  | X  | X  | ssh-dss                                  |
| X  | X  | X  | X  | X  | ssh-rsa-cert-v00@openssh.com             |
| X  | X  | X  | X  | X  | ssh-dss-cert-v00@openssh.com             |
| X  | X  | X  | X  | X  | ssh-rsa-cert-v01@openssh.com             |
| X  | X  | X  | X  | X  | ssh-dss-cert-v01@openssh.com             |
|    | X  | X  | X  | X  | ecdsa-sha2-nistp256                      |
|    | X  | X  | X  | X  | ecdsa-sha2-nistp384                      |
|    | X  | X  | X  | X  | ecdsa-sha2-nistp521                      |
|    | X  | X  | X  | X  | ecdsa-sha2-nistp256-cert-v01@openssh.com |
|    | X  | X  | X  | X  | ecdsa-sha2-nistp384-cert-v01@openssh.com |
|    | X  | X  | X  | X  | ecdsa-sha2-nistp521-cert-v01@openssh.com |
|    |    | X  | X  | X  | ssh-ed25519                              |
|    |    | X  | X  | X  | ssh-ed25519-cert-v01@openssh.com         |


KexAlgorithms
| sq | wh | je | st | si | type                                 |
=================================================================
| X  | X  | X  |    | X  | diffie-hellman-group-exchange-sha256 |
| X  | X  | X  |    | X  | diffie-hellman-group-exchange-sha1   |
| X  | X  | X  |    | X  | diffie-hellman-group14-sha1          |
| X  | X  | X  |    | X  | diffie-hellman-group1-sha1           |
|    | X  | X  |    | X  | ecdh-sha2-nistp256                   |
|    | X  | X  |    | X  | ecdh-sha2-nistp384                   |
|    | X  | X  |    | X  | ecdh-sha2-nistp521                   |
|    |    | X  |    | X  | curve25519-sha256@libssh.org         |

Ciphers
| sq | wh | je | st | si | type                          |
==========================================================
| X  | X  | X  | X  | X  | aes128-ctr                    |
| X  | X  | X  | X  | X  | aes192-ctr                    |
| X  | X  | X  | X  | X  | aes256-ctr                    |
| X  | X  | X  | X  | X  | arcfour                       |
| X  | X  | X  | X  | X  | arcfour256                    |
| X  | X  | X  | X  | X  | arcfour128                    |
| X  | X  | X  | X  | X  | aes128-cbc                    |
| X  | X  | X  | X  | X  | 3des-cbc                      |
| X  | X  | X  | X  | X  | blowfish-cbc                  |
| X  | X  | X  | X  | X  | cast128-cbc                   |
| X  | X  | X  | X  | X  | aes192-cbc                    |
| X  | X  | X  | X  | X  | aes256-cbc                    |
|    |    | X  | X  | X  | aes128-gcm@openssh.com        |
|    |    | X  | X  | X  | aes256-gcm@openssh.com        |
|    |    | X  | X  | X  | chacha20-poly1305@openssh.com |
|    |    | X  | X  | X  | rijndael-cbc@lysator.liu.se   |

MACs
| sq | wh | je | st | si   | type                           |
=============================================================
| X  | X  | X  | X  | X    | hmac-md5                       |
| X  | X  | X  | X  | X    | hmac-sha1                      |
| X  | X  | X  | X  | X    | umac-64@openssh.com            |
| X  | X  | X  | X  | X    | hmac-ripemd160                 |
| ?  | X  | X  | X  | X    | hmac-ripemd160@openssh.com     |
| X  | X  | X  | X  | X    | hmac-sha1-96                   |
| X  | X  | X  | X  | X    | hmac-md5-96                    |
| X  | X  | X  | X  | X    | hmac-sha2-256                  |
| X  | X  |    |    |      | hmac-sha2-256-96               | *
| X  | X  | X  | X  | X    | hmac-sha2-512                  |
| X  | X  |    |    |      | hmac-sha2-512-96               | *
|    |    | X  | X  | X    | umac-64-etm@openssh.com        |
|    |    | X  | X  | X    | umac-128-etm@openssh.com       |
|    |    | X  | X  | X    | hmac-sha2-256-etm@openssh.com  |
|    |    | X  | X  | X    | hmac-sha2-512-etm@openssh.com  |
|    |    | X  | X  | X    | umac-128@openssh.com           |
|    |    | X  | X  | X    | hmac-md5-etm@openssh.com       |
|    |    | X  | X  | X    | hmac-sha1-etm@openssh.com      |
|    |    | X  | X  | X    | hmac-ripemd160-etm@openssh.com |
|    |    | X  | X  | X    | hmac-sha1-96-etm@openssh.com   |
|    |    | X  | X  | X    | hmac-md5-96-etm@openssh.com    |

* https://bugzilla.mindrot.org/show_bug.cgi?id=2023

After I have a chance to look at these and think about the implications, I 
will send another message with thoughts about what disabling weaker things 
would mean.

HTH,

-- 
Matt Taggart
taggart@debian.org

Message #65 received at 774711@bugs.debian.org (full text, mbox, reply):

From: Matt Taggart <taggart@debian.org>

To: 774711@bugs.debian.org

Cc: taggart@debian.org

Subject: recommendations for changing openssh defaults

Date: Thu, 10 Sep 2015 17:09:16 -0700

Hi,

Based on the charts I already sent and using the recommendations from:

  https://stribika.github.io/2015/01/04/secure-secure-shell.html

and the openssh 7.0 release notes:

  http://www.openssh.com/txt/release-7.0

Here are some suggestions for changing the default things that are 
attempted. I think non-default support for all should be left in for some 
time, so that if needed they can be enabled on a case-to-case basis. Again, 
this is only about changing the defaults, not removing things (yet).

Also, Colin has expressed interesting in trying to stick with upstreams 
defaults as much as possible. So the recommendations here are maybe things 
we want to see happen in upstream rather than just in Debian. As Debian is 
one of the more conservative distros, if _we_ think it can be dropped from 
the default, hopefully upstream does too!

These are recommendations for stretch/sid primarily, but I also think they 
should be considered for jessie (or at least backported to 
jessie-backports, and wheezy-backports-sloppy once in stretch).

Keys
====
get rid of
* ssh-dss*: too small (1024), disabled upstream in 7.0
* NIST curves: known bad

keep:
* ssh-rsa*: existed forever, sha1 not a problem (as explained in above URL)
* ssh-ed25519*: introduced in jessie

Kex
===
get rid of
* NIST curves: known bad
* diffie-hellman-group1-sha1: too small (1024) and sha1
* diffie-hellman-group14-sha1: sha1
* diffie-hellman-group-exchange-sha1: sha1

keep
* curve25519-sha256: introduced in jessie
* diffie-hellman-group-exchange-sha256: has existed since squeeze at least

Ciphers
=======
get rid of
* 3des-cbc: DES is broken
* arcfour: RC4 is broken, disabled upstream in 7.0
* cast128-cbc: block size too small(64), disabled upstream in 7.0
* blowfish-cbc: disabled upstream in 7.0
* rijndael-cbc@lysator.liu.se: disabled upstream in 7.0

keep
* aes*-cbc: since squeeze
* aes*-ctr: since squeeze
* aes*-gcm: since squeeze
* chacha20-poly1305@openssh.com: since jessie

MACs
====
get rid of
* *md5*: MD5 is weak, disabled upstream in 7.0
* *sha1*: SHA1 is weak
* umac-64*: tag too small (64)

keep
* hmac-ripemd160: since squeeze
* hmac-sha2-*: since squeeze
* umac-128: since jessie
* hmac-ripemd160-etm@openssh.com: since jessie
* hmac-sha2-*-etm@openssh.com: since jessie

I _think_ because options remain in each thing that were available in all 
older releases, these recommendations should allow interop back to squeeze. 
(and futher if enabled case-by-case of course)

Thanks,

-- 
Matt Taggart
taggart@debian.org

Message #70 received at 774711@bugs.debian.org (full text, mbox, reply):

From: Jens Thiele <karme@karme.de>

To: Matt Taggart <taggart@debian.org>

Cc: 774711@bugs.debian.org

Subject: Re: Bug#774711: recommendations for changing openssh defaults

Date: Fri, 11 Sep 2015 10:32:54 +0200

Matt Taggart <taggart@debian.org> writes:

> Hi,

Hi,

thanks for your great work

> * diffie-hellman-group-exchange-sha256: has existed since squeeze at least

Afair I have seen small default primes with this one. Did you inspect this?

greetings,
jens

Message #75 received at 774711@bugs.debian.org (full text, mbox, reply):

From: Matt Taggart <taggart@debian.org>

To: Jens Thiele <karme@karme.de>

Cc: Matt Taggart <taggart@debian.org>, 774711@bugs.debian.org

Subject: Re: Bug#774711: recommendations for changing openssh defaults

Date: Fri, 11 Sep 2015 17:23:31 -0700

Jens Thiele writes:
> Hi,
> 
> thanks for your great work

I should make it clear, I was only applying the advice I found in

  https://stribika.github.io/2015/01/04/secure-secure-shell.html

to what versions exist in Debian, stribika and others get credit for that 
work.

Also I realized I had some mistakes in my charts/recommendations:

* I forgot to fill in the Kex stretch column (but it's the same as sid)
* I said "aes*-gcm: since squeeze" but it's only existed since jessie
* I said to keep aes*-cbc, but the above page doesn't list them in the
  recommended Ciphers list (I guess they aren't AE?), so drop them.

So for current openssh communicating with squeeze, that leaves only

Ciphers aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-512,hmac-sha2-256,hmac-ripemd160

in common but it will still work. I haven't looked at lenny.

> > * diffie-hellman-group-exchange-sha256: has existed since squeeze at least
> 
> Afair I have seen small default primes with this one. Did you inspect this?

I didn't.

-- 
Matt Taggart
taggart@debian.org

Message #80 received at 774711@bugs.debian.org (full text, mbox, reply):

From: Jens Thiele <karme@karme.de>

To: Matt Taggart <taggart@debian.org>

Cc: 774711@bugs.debian.org

Subject: Re: Bug#774711: recommendations for changing openssh defaults

Date: Mon, 14 Sep 2015 10:54:15 +0200

Matt Taggart <taggart@debian.org> writes:

> Jens Thiele writes:
>> Afair I have seen small default primes with this one.

I can't reproduce it (maybe my memory was just wrong).

>> Did you inspect this?
> I didn't.

I just did a quick test connecting 100 times from jessie to wheezy and
wheezy to wheezy[1]. Looks like primes are from the target system
/etc/ssh/moduli file and always 4095 bits => not really "small" (thought
I did see <=1024 bits)

(Only downside in this test: the number of primes of that length in
ssh/moduli is relatively small => they are reused quite often.)

But maybe someone can inspect this in more detail.

[1]
using something like:
unset GNOME_KEYRING_CONTROL GNOME_DESKTOP_SESSION_ID GNOME_KEYRING_PID \
 && dumpcap -q -i wlan0 -w - \
 |su nobody -c "tshark -d tcp.port==2222,ssh -Tfields \
  -e ssh.dh.g -e ssh.dh.p \
  -Y \
  'ssh and (ssh.dh.g or ssh.dh.p)' -r -" \
  |head -n100|sort|uniq -c|tee /tmp/primes

Message #85 received at 774711@bugs.debian.org (full text, mbox, reply):

From: Matt Taggart <taggart@debian.org>

To: 774711@bugs.debian.org

Subject: Re: Bug#774711: recommendations for changing openssh defaults

Date: Mon, 12 Oct 2015 21:25:57 -0700

Given the recent news about advances in causing SHA1 collisions, I think 
it's even more important for openssh to start not accepting known weak 
crypto (including sha1) by default.

  https://sites.google.com/site/itstheshappening/

I don't see any upstream bugs about this. Should this bug be forwarded? Or 
maybe separate bugs should be filed for MD5, SHA1, NIST, etc?

Thanks,

-- 
Matt Taggart
taggart@debian.org

Message #90 received at 774711@bugs.debian.org (full text, mbox, reply):

From: Matt Taggart <taggart@debian.org>

To: 774711@bugs.debian.org

Subject: Re: Bug#774711: recommendations for changing openssh defaults

Date: Mon, 12 Oct 2015 21:42:06 -0700

Also here are some interesting upstream messages that are relevant to this 
bug.

FYI: SSH1 now disabled at compile-time by default
Wed Mar 25 2015
https://lists.mindrot.org/pipermail/openssh-unix-dev/2015-March/033701.html

Obsolete MD5
Tue May 5 2015
https://lists.mindrot.org/pipermail/openssh-unix-dev/2015-May/033867.html

Weak DH primes and openssh
Thu May 28 2015
https://lists.mindrot.org/pipermail/openssh-unix-dev/2015-May/033966.html

-- 
Matt Taggart
taggart@debian.org

Message #95 received at 774711@bugs.debian.org (full text, mbox, reply):

From: Matt Taggart <taggart@debian.org>

To: 774711@bugs.debian.org

Subject: Re: Bug#774711: recommendations for changing openssh defaults

Date: Thu, 07 Jan 2016 12:09:21 -0800

It's now January 2016, one year since this bug was filed.

Some updates:

1) The recent 1:7.1p1-1 upload NEWS mentioned the following:

========================================================================
  OpenSSH 7.0 disables several pieces of weak, legacy, and/or unsafe
  cryptography.

   * Support for the legacy SSH version 1 protocol is disabled by default at
     compile time.  Note that this also means that the Cipher keyword in
     ssh_config(5) is effectively no longer usable; use Ciphers instead for
     protocol 2.  The openssh-client-ssh1 package includes "ssh1", "scp1",
     and "ssh-keygen1" binaries which you can use if you have no alternative
     way to connect to an outdated SSH1-only server; please contact the
     server administrator or system vendor in such cases and ask them to
     upgrade.
   * Support for the 1024-bit diffie-hellman-group1-sha1 key exchange is
     disabled by default at run-time.  It may be re-enabled using the
     instructions at http://www.openssh.com/legacy.html
   * Support for ssh-dss, ssh-dss-cert-* host and user keys is disabled by
     default at run-time.  These may be re-enabled using the instructions at
     http://www.openssh.com/legacy.html
   * Support for the legacy v00 cert format has been removed.

  Future releases will retire more legacy cryptography, including:

   * Refusing all RSA keys smaller than 1024 bits (the current minimum is
     768 bits).
   * Several ciphers will be disabled by default: blowfish-cbc, cast128-cbc,
     all arcfour variants, and the rijndael-cbc aliases for AES.
   * MD5-based HMAC algorithms will be disabled by default.
========================================================================

2) I also just noticed that the 1:6.7p1-1 changelog listed:
  sshd(8): The default set of ciphers and MACs has been altered to
  remove unsafe algorithms.  In particular, CBC ciphers and arcfour* are
  disabled by default.  The full set of algorithms remains available if
  configured explicitly via the Ciphers and MACs sshd_config options.
That is in the server, so I guess the references in NEWS above to
cbc/arcfour going away soon must mean the client.

3) An interesting paper was released that mentions loss of security in ssh 
when using sha1 in key exchange,
  http://www.mitls.org/pages/attacks/SLOTH
As mentioned above diffie-hellman-group1-sha1 was already disabled by 
default. Perhaps this is more evidence diffie-hellman-group14-sha1 and 
diffie-hellman-group-exchange-sha1 should be as well?
I don't know what implications this has for rsa's use of sha1, but it's 
looking worse all the time. Maybe it would be good to have a plan, rsa keys 
are going to be really hard to get rid of and will probably require a 
multi-year warning.

4) The recent Juniper VPN firewall hack reminds us and provides further 
evidence that the NIST curves are compromised and should be disabled 
immediately,
http://blog.cryptographyengineering.com/2015/12/on-juniper-backdoor.html

5) the md5 and sha1 MACs should start going away, probably umac-64* too. 
This should be easy, there are plenty of alternatives.

It's good to see some progress on this front, I think disabling a few more 
things will get us to a much more secure state.

Thanks,

-- 
Matt Taggart
taggart@debian.org

Message #100 received at 774711@bugs.debian.org (full text, mbox, reply):

From: Matt Taggart <taggart@debian.org>

To: 774711@bugs.debian.org

Cc: taggart@debian.org

Subject: openssh and putty

Date: Thu, 05 May 2016 14:24:11 -0700

Today I was wondering about what crypto puTTY supports and the implications 
for openssh support in Debian and restricting options as we've been 
discussing in #774711. Here is what I found:

=======================================================================
puTTY -http://www.chiark.greenend.org.uk/~sgtatham/putty/
current released version 0.67

Documented at
http://the.earth.li/~sgtatham/putty/0.67/htmldoc/Chapter4.html

The following are supported in 0.67, described as openssh option names and 
for newer options the date and release they first appeared in puTTY.

Keys (in sshrsa.c, sshdss.c,sshecc.c)
* ssh-rsa
* ssh-dss
* ecdsa-sha2-nistp256, ecdsa-sha2-nistp384, ecdsa-sha2-nistp521 
(2014-11-02,0.64)
* ssh-ed25519 (2015-05-09, 0.65)

KEX (in sshdh.c, sshecc.c)
* diffie-hellman-group-exchange-sha256
* diffie-hellman-group14-sha1
* diffie-hellman-group1-sha1
* diffie-hellman-group-exchange-sha1
* ecdh-sha2-nistp256, ecdh-sha2-nistp384, ecdh-sha2-nistp521 
(2014-11-02,0.64))
* curve25519-sha256@libssh.org (2015-05-09, 0.65)

cipher (in sshaes.c, ssharcf.c, sshblowf.h, sshdes.c, sshccp.c)
* aes256-ctr, aes192-ctr, aes128-ctr
* aes256-cbc, aes192-cbc, aes128-cbc
* rijndael-cbc@lysator.liu.se
* arcfour256, arcfour128
* blowfish-cbc(128), blowfish-ctr(256, openssh support?)
* 3des-cbc, 3des-ctr(openssh support?)
* chacha20-poly1305@openssh.com (2015-06-07, 0.65)

MAC (in sshsha.c, sshsh256.c sshsh512.c, sshmd5.c, )
* hmac-md5, hmac-md5-etm@openssh.com
* hmac-sha1, hmac-sha1-etm@openssh.com
* hmac-sha1-96, hmac-sha1-96-etm@openssh.com
* hmac-sha2-256, hmac-sha2-256-etm@openssh.com (2013-02-20, 0.63)
=======================================================================

If you want to support squeeze(released 2011-02) and newer and putty 
0.63(released 2013-08) and newer (and you agree with the other decisions 
mentioned in this bug, like dropping rsa1/md5/des/ecdsa) then the minimum 
modern options you need are:

=======================================================================
HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com, ssh-ed25519,\
    ssh-rsa-cert-v01@openssh.com, ssh-rsa-cert-v00@openssh.com,ssh-rsa

KexAlgorithms curve25519-sha256@libssh.org,\
    diffie-hellman-group-exchange-sha256

Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,
    aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,\
    hmac-ripemd160-etm@openssh.com,umac-128-etm@openssh.com,\
    hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,umac-128@openssh.com
=======================================================================

If people encounter other implementations of ssh that can't communicate 
with a debian system using the above, please report it to #774711 as it has 
implicationson what debian/upstream need to support/document.

HTH,

-- 
Matt Taggart
taggart@debian.org

Message #105 received at 774711@bugs.debian.org (full text, mbox, reply):

From: Jacob Nevins <jacobn+debian@chiark.greenend.org.uk>

To: 774711@bugs.debian.org

Subject: Re: openssh and putty

Date: Fri, 6 May 2016 09:47:34 +0100

Matt Taggart writes:
> * ecdh-sha2-nistp256, ecdh-sha2-nistp384, ecdh-sha2-nistp521
> (2014-11-02,0.64))
> * curve25519-sha256@libssh.org (2015-05-09, 0.65)

This and other items appear to infer which PuTTY releases contain
features by comparing the dates the features were checked in to master
and the release dates of PuTTY releases.

In fact PuTTY 0.64-0.67 inclusive were released from branches.
Elliptic-curve algorithms are not yet in any released version of PuTTY.
<http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/> refers.

> If you want to support squeeze(released 2011-02) and newer and putty 
> 0.63(released 2013-08) and newer [...] then the minimum modern options
> you need are: [...]

(The above doesn't change your conclusion here though.)

Message #110 received at 774711@bugs.debian.org (full text, mbox, reply):

From: Matt Taggart <taggart@debian.org>

To: 774711@bugs.debian.org

Subject: update of current openssh crypto support

Date: Tue, 14 Feb 2017 11:16:39 -0800

It's been a while since I have updated #774711 with current status of
openssh crypto. Since my last update the following things were deprecated,

7.4:
* cipher: drops 3des-cbc from client proposal

7.2:
* cipher: drops blowfish-cbc, cast128-cbc, all arcfour variants
   and the rijndael-cbc aliases for AES
* HMAC: drops MD5-based and truncated HMAC algorithms
* increase the minimum modulus size supported for
   diffie-hellman-group-exchange to 2048 bits

7.0:
* protocol: v.1 disabled by default at compile time
* 1024-bit diffie-hellman-group1-sha1 key exchange disabled by default
   at run time
* ssh-dss, ssh-dss-cert-* host and user keys is disabled
   by default at run-time
* legacy v00 cert format has been removed

We also know that around Aug 2017 the following is coming:
* protocol: fully dropping support for v.1 (already disabled)
* ciphers: removing Blowfish and RC4
* HMAC: remove RIPE-MD160
* keys: refuse RSA keys smaller than 1024 bits

Of the things I listed that should be considered for removal in my mail 
to this bug on 10 Sep 2015
( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774711#65 )
only the following things remain supported:

Keys:
* NIST curves

Kex:
* NIST curves
* diffie-hellman-group14-sha1
* diffie-hellman-group-exchange-sha1 (min 2048 now at least)

Ciphers: done!

MACs:
* sha1
* umac-64

Anyone know the upstream status of these remaining things?

Thanks,

-- 
Matt Taggart
taggart@debian.org

Message #115 received at 774711@bugs.debian.org (full text, mbox, reply):

From: Matt Taggart <taggart@debian.org>

To: 774711@bugs.debian.org

Subject: openssh 7.6 changes

Date: Fri, 20 Apr 2018 15:04:39 -0700

Hi,

Just a quick update on #774711. As pre-announced in earlier releases,
OpenSSH 7.6 did drop support for some old unsafe crypto options:

* dropped SSHv1 protocol support
* removed hmac-ripemd160 MAC
* removed arcfour, blowfish and CAST ciphers
* refuses RSA keys <1024 bits in length
* does not offer CBC ciphers by default

As far as I know, the following potentially unsafe things are still
supported in 7.7:

Keys:
* NIST curves

Kex:
* NIST curves
* diffie-hellman-group14-sha1
* diffie-hellman-group-exchange-sha1 (min 2048 now at least)

MACs:
* sha1
* umac-64

Debian users wanting to drop support for the legacy crypto options
mentioned previously in this bug can use the following:

=======================================================================
HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com, ssh-ed25519,\
    ssh-rsa-cert-v01@openssh.com, ssh-rsa-cert-v00@openssh.com,ssh-rsa

KexAlgorithms curve25519-sha256@libssh.org,\
    diffie-hellman-group-exchange-sha256

Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,
    aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,\
    umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,\
    umac-128@openssh.com
=======================================================================


-- 
Matt Taggart
taggart@debian.org

Message #120 received at 774711@bugs.debian.org (full text, mbox, reply):

From: Cristian Ionescu-Idbohrn <cristian.ionescu-idbohrn@axis.com>

To: Matt Taggart <taggart@debian.org>, 774711@bugs.debian.org

Subject: Re: Bug#774711: openssh 7.6 changes

Date: Sat, 21 Apr 2018 11:08:27 +0200 (CEST)

On Fri, 20 Apr 2018, Matt Taggart wrote:
> 
> Debian users wanting to drop support for the legacy crypto options
> mentioned previously in this bug can use the following:
> 
> =======================================================================
> HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com, ssh-ed25519,\
>     ssh-rsa-cert-v01@openssh.com, ssh-rsa-cert-v00@openssh.com,ssh-rsa
> 
> KexAlgorithms curve25519-sha256@libssh.org,\
>     diffie-hellman-group-exchange-sha256
> 
> Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,
>     aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
> 
> MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,\
>     umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,\
>     umac-128@openssh.com
> =======================================================================

There's also another way to do it (see `man 5 ssh{,d}_config'):

             If the specified value begins with a '-' character, then the
             specified methods (including wildcards) will be removed from the
             default set instead of replacing them.

introduced in version 7.5,
upstream commit 68bc8cfa7642d3ccbf2cd64281c16b8b9205be59.

Note: all excluded values must be given on one line; example:

	KexAlgorithms -diffie-hellman-group14-sha1,ecdh-sha2-nistp*


Cheers,

-- 
Cristian

Message #125 received at 774711@bugs.debian.org (full text, mbox, reply):

From: Mathew Binkley <mathew.binkley@vanderbilt.edu>

To: <774711@bugs.debian.org>

Subject: Default sshd_config in Debian Testing is insecure as of Oct 1, 2018

Date: Mon, 1 Oct 2018 17:11:53 -0500

[Message part 1 (text/plain, inline)]

I have been hardening the SSH daemon on servers at work using two
auditing tools:

* https://github.com/arthepsy/ssh-audit

* The similarly named yet apparently unaffiliated https://www.sshaudit.com

The latter assigns a numerical score to the security of
ciphers/algorithms enabled by the SSH server daemon.

The "out-of-the-box" score for OpenSSH on Debian Testing (the ISO
available as of Oct 1, 2018) is only 47 out of 100.   There are numerous
weak ciphers/algorithms/protocols enabled by default (please see
attached PDF file for the audit report)..

I just wanted to point out these two auditing tools to make it easier to
recognize the insecure settings.  Given that Debian sometimes has to
trade off maximum security for compatibility with older clients, it
might be useful to add config lines to sshd_config that would score
100/100, and then comment them out.  That would make it easy for power
users to enable and tighten up their config, while still making the
default compatible (or whatever the particular balance might require).


Mat

[Ubuntu-Testing-Oct_1_2018.pdf (application/pdf, attachment)]

Message #130 received at 774711@bugs.debian.org (full text, mbox, reply):

From: Matt Taggart <matt@lackof.org>

To: 774711@bugs.debian.org

Cc: Mathew Binkley <mathew.binkley@vanderbilt.edu>

Subject: OpenSSH settings hardening

Date: Wed, 17 Aug 2022 17:08:11 -0700

Hi,

Some updates on OpenSSH config hardening

1) The ssh-audit tool that Mathew Binkley pointed out has been forked 
and updated and lives at

  https://github.com/jtesta/ssh-audit

2) The sshaudit.com site now uses the above version.

3) The sshaudit.com site also now provides a hardening guide

  https://www.ssh-audit.com/hardening_guides.html

that was inspired by the original stribika.github.io page mentioned here.

I like Mathew's idea of aiming for a config that scores well, with 
commented out configs for enabling compatibility for older clients.

-- 
Matt Taggart
matt@lackof.org

Message #135 received at 774711@bugs.debian.org (full text, mbox, reply):

From: Matt Taggart <matt@lackof.org>

To: 774711@bugs.debian.org

Subject: update of debian openssh crypto defaults

Date: Tue, 4 Oct 2022 15:05:15 -0700

It has been a while since I reviewed the state of #774711 compared to 
upstream. First here are the relevant changelog entries since I last did.

7.5
ssh(1), sshd(8): Support "=-" syntax to easily remove methods from
      algorithm lists, e.g. Ciphers=-*cbc.

7.6
ssh(1): Delete SSH protocol version 1 support, associated
      configuration options and documentation (LP: #1584321).
ssh(1)/sshd(8): Remove support for the hmac-ripemd160 MAC.
ssh(1)/sshd(8): Remove support for the arcfour, blowfish and CAST
      ciphers.
Refuse RSA keys <1024 bits in length and improve reporting for keys 
              that do not meet this requirement.
ssh(1): Do not offer CBC ciphers by default.

7.8
ssh(1)/sshd(8): Add new signature algorithms "rsa-sha2-256-cert-
      v01@openssh.com" and "rsa-sha2-512-cert-v01@openssh.com" to 
explicitly
      force use of RSA/SHA2 signatures in authentication.

8.0
ssh-keygen(1): Increase the default RSA key size to 3072 bits,
      following NIST Special Publication 800-57's guidance for a 128-bit
      equivalent symmetric security level (LP: #1445625).

8.1
ssh(1), sshd(8): Allow prepending a list of algorithms to the default
      set by starting the list with the '^' character, e.g.
      "HostKeyAlgorithms ^ssh-ed25519".

8.2
ssh(1), sshd(8), ssh-keygen(1): this release removes the "ssh-rsa"
      (RSA/SHA1) algorithm from those accepted for certificate signatures
      (i.e. the client and server CASignatureAlgorithms option) and 
will use
      the rsa-sha2-512 signature algorithm by default when the 
ssh-keygen(1)
      CA signs new certificates.
ssh(1), sshd(8): Remove diffie-hellman-group14-sha1 from the default
      key exchange proposal for both the client and server.

8.5 

ssh(1), sshd(8): change the first-preference signature algorithm from
      ECDSA to ED25519.
ssh(1), sshd(8): remove the pre-standardization cipher
      rijndael-cbc@lysator.liu.se.

8.8
This release disables RSA signatures using the SHA-1 hash algorithm by
      default.  (Existing RSA keys may still be used and do not need to be
      replaced; see NEWS.Debian if you have problems connecting to old SSH
      servers.)

8.9
ssh(1), ssh(8): since DSA keys are deprecated, move them to the end of
      the default list of public keys so that they will be tried last.

From my last comparison on 20 Apr 2018, the following unsafe things are 
still supported in 9.0 and debian:

======================================================================
Keys:
* NIST curves (ecdsa-sha2-nistp256, ecdsa-sha2-nistp384, 
ecdsa-sha2-nistp521)

Kex:
* NIST curves (ecdh-sha2-nistp256, ecdh-sha2-nistp384, ecdh-sha2-nistp521)
* diffie-hellman-group14-sha1, diffie-hellman-group-exchange-sha1
    (supported, but no longer in the default set))

MACs:
* umac-64
======================================================================

Those are the things remaining from the original "stribika" analysis. 
The new ssh-audit.com recommendations are similar and disable the following:

======================================================================
Ciphers:
* 3des-cbc
* aes128-cbc aes192-cbc aes256-cbc
* rijndael-cbc@lysator.liu.se

Kex:
* ecdh-sha2-nistp256 ecdh-sha2-nistp384 ecdh-sha2-nistp521
* diffie-hellman-group14-sha256
* diffie-hellman-group1-sha1 diffie-hellman-group14-sha1

MACs
* umac-64-etm@openssh.com umac-64@openssh.com
* hmac-sha1-etm@openssh.com hmac-sha1
* umac-128@openssh.com  (prefers umac-128-etm@openssh.com)
* hmac-sha2-256 (prefers hmac-sha2-256-etm@openssh.com)
* hmac-sha2-512 (prefers hmac-sha2-512-etm@openssh.com)


HostKeyAlgorithms:
* ecdsa-sha2-nistp256 ecdsa-sha2-nistp384 ecdsa-sha2-nistp521
* ecdsa-sha2-nistp256-cert-v01@openssh.com
  ecdsa-sha2-nistp384-cert-v01@openssh.com
  ecdsa-sha2-nistp521-cert-v01@openssh.com
* sk-ecdsa-sha2-nistp256-cert-v01@openssh.com
  sk-ecdsa-sha2-nistp256@openssh.com
* ssh-rsa-cert-v01@openssh.com ssh-rsa

======================================================================

This mostly matches the original "stribika" which it is based on, here 
are some observations:

* The Ciphers they recommend removing:
  3des rijndael-cbc@lysator.liu.se aes128-cbc aes192-cbc aes256-cbc
dropped off the radar here because are all disabled by default, but it 
is now well past the time to disable them completely in the server (and 
possibly the client)
* Similarly, Kex:diffie-hellman-group*-sha1 and MAC:umac-64 should be 
fully disabled in the server, and soon the client.
* HostKeyAlgorithms:ssh-rsa/ssh-rsa-cert-v01@openssh.com are dropped in 
8.2. They should go away but I am unsure when.
* In some cases they prefer the longer "@openssh.com" version, and don't 
explicitly list the short name, I don't know why.
* Why are NIST curves still enabled? They've been proven harmful for 8+ 
years.


Using the new '=-','^','+','-','*' syntax, it is possible to specify 
configuration changes relative to the default, in a way that 
future-proofs the config for additions/removals in future upstream 
versions. Right now that might look something like

======================================================================
Ciphers -3des-cbc,aes*-cbc,rijndael-cbc@lysator.liu.se

KexAlgorithms -ecdh-sha2-nistp*,,
    diffie-hellman-group14-*,diffie-hellman-group1-sha1

MACs -umac-64*,hmac-sha1*,umac-128@openssh.com,
    hmac-sha2-256,hmac-sha2-512

HostKeyAlgorithms -ecdsa-sha2-nistp*, sk-ecdsa-sha2-nistp*,
    ssh-rsa-cert-v01@openssh.com,ssh-rsa
======================================================================

But one might choose to explicitly list the things to enable to prevent 
surprises (at the risk of continuing to support something that upstream 
drops from the default).

When I set out to write this, I was hoping everything in the original 
report had been dealt with by now, there has been a lot of progress 
upstream. But it seems there are still a few things left, let push to 
get this done!

Thanks,

-- 
Matt Taggart
matt@lackof.org

Message #140 received at 774711@bugs.debian.org (full text, mbox, reply):

From: Matt Taggart <matt@lackof.org>

To: 1000198@bugs.debian.org

Cc: 774711@bugs.debian.org

Subject: RE: openssh-server: insecure algorithms reported by ssh-audit

Date: Tue, 4 Oct 2022 16:59:43 -0700

Thanks for the ssh-audit report output!
There has been a very long discussion of default settings in #774711 
(which now includes ssh-audit's recommendations)

Since you generated this report the following has happened:

* 1:8.8p1-1:
  "This release disables RSA signatures using the SHA-1 hash algorithm
   by default.  (Existing RSA keys may still be used and do not need
   to be replaced; see NEWS.Debian if you have problems connecting to
   old SSH servers.)"
* 1:8.9p1-1:
  "ssh(1): stricter UpdateHostkey signature verification logic on the
   client-side. Require RSA/SHA2 signatures for RSA hostkeys except when
   RSA/SHA1 was explicitly negotiated during initial KEX.
   ssh(1), sshd(8): fix signature algorithm selection logic for
   UpdateHostkeys on the server side. The previous code tried to prefer
   RSA/SHA2 for hostkey proofs of RSA keys, but missed some cases. This
   will use RSA/SHA2 signatures for RSA keys if the client proposed
   these algorithms in initial KEX."
* 1:9.0p1-1:
  "use the hybrid Streamlined NTRU Prime + x25519 key exchange method
   by default ("sntrup761x25519-sha512@openssh.com"). The NTRU algorithm
   is believed to resist attacks enabled by future quantum computers and
   is paired with the X25519 ECDH key exchange (the previous default) as
   a backstop against any weaknesses in NTRU Prime that may be
   discovered in the future. The combination ensures that the hybrid
   exchange offers at least as good security as the status quo."
* sk-ssh-ed25519@openssh.com is the defaults lists now

The rest of ssh-audit's recommendations from your report are still 
valid, see #774711 for more info

-- 
Matt Taggart
matt@lackof.org

Send a report that this bug log contains spam.