nixos/sshd: add options for kexAlgorithms, ciphers and MACs

[infinisil]

Motivation for this change

These settings were previously hardcoded in sshd's config. I noticed this because I needed to change them because of mssun/passforios#153 (comment).

Edit: The other way of adding defaults (config.services.sshd.kexAlgorithms = mkDefault [ ... ]) doesn't seem appropriate here, because the default wouldn't be visible in the man page and doing kexAlgorithms = [ ... ] in your config would add to the default ones instead of overriding the default, which seems slightly dangerous for security. To add to the default ones with the current config you need to use kexAlgorithms = options.services.sshd.kexAlgorithms.default ++ [ ... ]

Things done

Testing in progress..

• Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-sandbox in nix.conf on non-NixOS)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Fits CONTRIBUTING.md.

---

[infinisil]

Ping @jeaye @NeQuissimus @peterhoeg

[jeaye]

Makes sense to me. Thanks for making this much more easily configurable.

[peterhoeg]

Nice!

[grahamc]

(see comments)

[grahamc]

We should probably revert this to not specify defaults for this option,

[grahamc]

this option,

[grahamc]

and then only write these out if the options are specified.

This way, we don't have to maintain our own default list which will inevitably become out of sync with sshd's recommended options.

[infinisil]

We do need a default, we can't just have everybody specify what algs to use in their config all the time. You couldn't just services.openssh.enable = true and have a working openssh anymore.

[grahamc]

They won't need to, from man ssh_config:

       KexAlgorithms
              Specifies the available  KEX  (Key  Exchange)  algo‐
              rithms.   Multiple  algorithms  must  be comma-sepa‐
              rated.  Alternately if the  specified  value  begins
              with  a  `+'  character,  then the specified methods
              will be appended  to  the  default  set  instead  of
              replacing  them.  If the specified value begins with
              a `-' character, then the specified methods (includ‐
              ing  wildcards) will be removed from the default set
              instead of replacing them.  The default is:

              curve25519-sha256,[email protected],
              ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-
              sha2-nistp521,
              diffie-hellman-group-exchange-sha256,
              diffie-hellman-group-exchange-sha1,
              diffie-hellman-group14-sha1

              The  list  of  available key exchange algorithms may
              also be obtained using Qq ssh -Q kex .

       Ciphers
              Specifies the ciphers allowed  and  their  order  of
              preference.   Multiple  ciphers  must be comma-sepa‐
              rated.  If the specified value  begins  with  a  `+'
              character,   then  the  specified  ciphers  will  be
              appended to the default  set  instead  of  replacing
              them.   If  the  specified  value  begins with a `-'
              character, then  the  specified  ciphers  (including
              wildcards)  will  be  removed  from  the default set
              instead of replacing them.

              The supported ciphers are:

              3des-cbc
              aes128-cbc
              aes192-cbc
              aes256-cbc
              aes128-ctr
              aes192-ctr
              aes256-ctr
              [email protected]
              [email protected]
              [email protected]

              The default is:

              [email protected],
              aes128-ctr,aes192-ctr,aes256-ctr,
              [email protected],[email protected],
              aes128-cbc,aes192-cbc,aes256-cbc

       MACs   Specifies  the  MAC  (message  authentication  code)
              algorithms in order of preference.   The  MAC  algo‐
              rithm is used for data integrity protection.  Multi‐
              ple algorithms  must  be  comma-separated.   If  the
              specified  value  begins  with a `+' character, then
              the specified algorithms will  be  appended  to  the
              default set instead of replacing them.  If the spec‐
              ified value begins with a `-'  character,  then  the
              specified  algorithms  (including wildcards) will be
              removed from the default set  instead  of  replacing
              them.

              The  algorithms  that  contain Qq -etm calculate the
              MAC after encryption (encrypt-then-mac).  These  are
              considered safer and their use recommended.

              The default is:

              [email protected],[email protected],
              [email protected],hmac-
              [email protected],
              [email protected],
              [email protected],[email protected],
              hmac-sha2-256,hmac-sha2-512,hmac-sha1

              The list of available MAC  algorithms  may  also  be
              obtained using Qq ssh -Q mac .

[infinisil]

These are insecure defaults, see https://stribika.github.io/2015/01/04/secure-secure-shell.html (linked from the options descriptions), and the PR that added such defaults originally: #31763

[grahamc]

cc @andir and @fpletz for an opinion here

[jeaye]

The way I see it, these should either be provided by default, as they care now, or as a secure profile, which was the original discussion point which sparked me to originally do the work. However,

1. We should maintain these settings in some profile, default or otherwise.
2. Should the secure settings not be the default settings?

Yes, this is additional work for NixOS security maintenance, but it's better for the security of every NixOS user, by default, and it doesn't make anything harder for them.

[grahamc]

My opinion is if they are in any profile it should be The Default.

[andir]

I see the point of the ageing cipher selection and having to maintain them. As @grahamc said we will "inevitably become out of sync" with whatever options one might deem as the holy grail of secure defaults.

BUT I also would argue that we need sane defaults. The defaults supplied by OpenSSH are probably not was many people would prefer.

I agree with Graham that if we have a "secure" profile that should be the default. If we had a "paranoid" profile that could be opt-in. If you have to downgrade your settings then you would disable the profile (services.openssh.server.profiles.default.enable = false, or some better option) and/or just define your custom list of algorithms.

How about we attempt to remove old (and "insecure") algorithms instead with the - qualifier? That would potentially allow new ciphers (which should be more secure?!?) to be picked up while we can easily disable ciphers as required.

I am not really happy with my proposal either. I would really like that the people dealing with the OpenSSH packaging would also maintain this list. They should come across changes in ciphersuites while reading the change logs anyway. The problem there is that it is yet another burden for a small number of people...

[Ekleog]

(Maybe stupid) idea: have some tag we can grep for in the source code saying “This will need to be reviewed before XXXX-XX-XX and every Y months/years”, and have someone setup a cron to automatically warn when XXXX-XX-XX is passed without this tag being updated?

This would simplify maintenance of such lists, for which I guess OpenSSH wouldn't be the sole user. And I don't think there is a big hurry for upgrade (or else everyone will hear about it): from my limited experience, when a cipher breaks, it breaks slowly over time, and not in a few months. Like, everyone have known for a while that SHA1 is not really secure, yet it still stays relatively OK for quite a lot of use cases.

[peterhoeg]

Instead of having to maintain a list of ciphers, which will be outdated as mentioned by grahamc, why not instead have our default settings blacklist the known bad ones using the "-" operator? This way when upstream adds "fancy-new-cipher", it will still be available and we are sure to block the bad ones.

[infinisil]

@peterhoeg new != secure though, e.g. The NIST ones which were added not too long ago "can't be trusted" according to the article. Also new algs might be experimental and not heavily tested. If openssh only adds new ones to the defaults when they have been well reviewed, I'm onboard with that idea.

[peterhoeg]

If openssh only adds new ones to the defaults when they have been well reviewed

I have no idea how they do this, but we essentially have 3 options:

1. Leave it to upstream (no maintenance, but insecure)
2. Maintain our own white-list which will get out of date
3. Maintain our own black-list which may mean the introduction of possibly insecure ciphers

I think option 3 is "Least-Bad (tm)".

[pstn]

Could this please be back ported to stable? Currently there is no way to specify ciphers there and the defaults lead to breakage with syncorg git integration on android.