- Package:
- src:openssh
- Source:
- openssh
- Submitter:
- Vasil Kolev
- Date:
- 2024-06-12 16:54:02 UTC
- Severity:
- important
- Tags:
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 ***
... 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 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 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. Unfortunately Debian usually rather goes the way less secure for everyone, just to please some oldish systems whose admins haven't done their homework, 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.
Christoph Anton Mitterer <calestyo@scientia.net> writes: 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
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.
Sure, as I mention in in #74793)...but what if they don't?
Cheers,
Chris.
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
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. "
Jens Thiele <karme@karme.de> writes: 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
I'd remove at least these completely. 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 Still below "Long term protection", according to ECRYPT II More of these! It shouldn't be a problem if the groups are pre-competed (and thus known to the attacker). 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'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.
Matt Taggart writes.... 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,
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,
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> writes: Hi, thanks for your great work Afair I have seen small default primes with this one. Did you inspect this? greetings, jens
Jens Thiele writes: 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. I didn't.
Matt Taggart <taggart@debian.org> writes: I can't reproduce it (maybe my memory was just wrong). 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
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,
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
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,
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 writes: 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. (The above doesn't change your conclusion here though.)
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,
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
=======================================================================
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,
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
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.
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,
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
So it's been a while this bug was discussed, and even more since when it was opened. Things have changed, since. SHA-1 has been retired in OpenSSH 7, for example... Is this still relevant? taggart, how did you generate those nice tables, can you make them again? :)