Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

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

84 views
Skip to first unread message

Vasil Kolev

unread,
Jan 6, 2015, 12:00:04 PM1/6/15
to
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)


--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Matthew Vernon

unread,
Jan 7, 2015, 10:30:03 AM1/7/15
to
Christoph Anton Mitterer <cale...@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

Matt Taggart

unread,
Apr 20, 2018, 6:10:03 PM4/20/18
to
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-ed2551...@openssh.com, ssh-ed25519,\
ssh-rsa-...@openssh.com, ssh-rsa-...@openssh.com,ssh-rsa

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

Ciphers chacha20...@openssh.com,aes25...@openssh.com,
aes12...@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

MACs hmac-sha...@openssh.com,hmac-sha...@openssh.com,\
umac-1...@openssh.com,hmac-sha2-512,hmac-sha2-256,\
umac...@openssh.com
=======================================================================


--
Matt Taggart
tag...@debian.org

Cristian Ionescu-Idbohrn

unread,
Apr 21, 2018, 5:20:02 AM4/21/18
to
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-ed2551...@openssh.com, ssh-ed25519,\
> ssh-rsa-...@openssh.com, ssh-rsa-...@openssh.com,ssh-rsa
>
> KexAlgorithms curve255...@libssh.org,\
> diffie-hellman-group-exchange-sha256
>
> Ciphers chacha20...@openssh.com,aes25...@openssh.com,
> aes12...@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
>
> MACs hmac-sha...@openssh.com,hmac-sha...@openssh.com,\
> umac-1...@openssh.com,hmac-sha2-512,hmac-sha2-256,\
> umac...@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

Matt Taggart

unread,
Aug 17, 2022, 8:20:03 PM8/17/22
to
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
ma...@lackof.org

Matt Taggart

unread,
Oct 4, 2022, 6:20:04 PM10/4/22
to
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-
v...@openssh.com" and "rsa-sha2-5...@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
rijnda...@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
* rijnda...@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-...@openssh.com uma...@openssh.com
* hmac-s...@openssh.com hmac-sha1
* umac...@openssh.com (prefers umac-1...@openssh.com)
* hmac-sha2-256 (prefers hmac-sha...@openssh.com)
* hmac-sha2-512 (prefers hmac-sha...@openssh.com)


HostKeyAlgorithms:
* ecdsa-sha2-nistp256 ecdsa-sha2-nistp384 ecdsa-sha2-nistp521
* ecdsa-sha2-nis...@openssh.com
ecdsa-sha2-nis...@openssh.com
ecdsa-sha2-nis...@openssh.com
* sk-ecdsa-sha2-n...@openssh.com
sk-ecdsa-sh...@openssh.com
* ssh-rsa-...@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 rijnda...@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-...@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,rijnda...@lysator.liu.se

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

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

HostKeyAlgorithms -ecdsa-sha2-nistp*, sk-ecdsa-sha2-nistp*,
ssh-rsa-...@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
ma...@lackof.org

Matt Taggart

unread,
Oct 4, 2022, 8:10:03 PM10/4/22
to
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 ("sntrup761x2...@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-...@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
ma...@lackof.org
0 new messages