In its postinst, openssh-server currently generates host keys with upstream defaults. While there's nothing inherently wrong with that, a more proactive approach to strong cryptography might be desirable.

The homepage of the auditing tool 'ssh-audit' suggests [1] using the following keygen recipes instead:

ssh-keygen -t rsa -b 4096 -f /etc/ssh/ssh_host_rsa_key -N ""
ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N ""

The key difference with upstream defaults (and openssh-server postinst) and the above is the enforcement of 4096-bit RSA keys.

It would be extremely desirable for Debian to implement this out of the box.

Thanks!
Martin-Éric

[1] https://www.sshaudit.com/hardening_guides.html#debian_12

Control: severity -1 wishlist

ssh-keygen's current default for RSA is 3072 bits.  I know people always
go for "bigger is better", but that's not actually quite clear here.

Firstly, why 4096?  People often seem to get there by just doubling 2048
because doubling feels like a natural thing to do with computers, but
it's not obvious that there's a particular reason to do that here.  NIST
SP 800-57 Part 1 Revision 5 estimates that breaking 3072-bit RSA keys is
about a factor of 2^16 more work than 2048-bit, and says that the
security level of 3072-bit RSA keys is acceptable through 2031 and
beyond.  (NIST SP 800-56Br2 estimates that breaking 4096-bit is a
further factor of 2^24 more work on top of that.)  Given that that's the
latest time window they specify anything for, I interpret that as "it's
not yet worth trying to guess what the landscape is going to look like
after that".

Secondly, RSA's performance gets noticeably worse with very large key
sizes.  Signing with a 4096-bit key is on the order of three times as
slow as signing with a 3072-bit key.  Admittedly, this is just the host
key so it probably only matters for things like key exchange on
connection establishment and rekeying; but if the difference is between
completely impractical to attack with any vaguely suspected
non-quantum-computer technology for the foreseeable future and even more
completely impractical to attack, it's not clear that it's worth the
trouble.

Thirdly, OpenSSH prefers to use Ed25519 host keys if it can agree those
between server and client.  Those have an estimated security strength of
128 bits, the same as 3072-bit RSA (as well as being faster, and
better-designed to defend against side-channel attacks) - so it's not
clear it's worth fiddling with the RSA host key length.

Fourthly, by the time any even remotely plausible attacks on 3072-bit
RSA keys appear, I suspect we'll mostly be using different host key
algorithms anyway.  Maybe that's Ed448, or maybe it's some kind of PQC
thing (on which I am in no way an expert).  My crystal ball isn't really
up to the task.

Fifthly, the ssh-audit hardening guide doesn't give any particular
argument for why 3072-bit RSA keys are inadequate here.  It amounts to
"bigger is better" - OK, but that's not actually a reason for stopping
at 4096 either, and so I'd rather have well-reasoned opinions from
cryptographers.  The current upstream defaults and things like NIST
standards are my best available proxy for that.

For all these reasons, I'm disinclined to say that I know better than
upstream here.  3072-bit RSA seems like a fine default at the moment,
and I expect that Debian will follow future changes made upstream.

Thanks,

Hi Colin,

while I fully agree and don't think that the debian package should
divert from upstream here, as an admin I do use different defaults for
systems I maintain.

From a config management point of view, this is very cumbersome as the
postinst do re-create missing things/fallback to upstream defaults.

To make it nicer for admins to locally deviate from the defaults.. how
about internal preseed option(s) not shown to the user to select
host-keys to be generated? Would you accept patches for this?

Regards,
Daniel

Hello both,
su 26.1.2025 klo 19.35 Daniel Baumann (daniel@debian.org) kirjoitti:

I have noticed this as well e.g. whenever Debian ships a new
openssh-server package, I've had to manually run the command shown on
the hardening guide to remove modulus below 3272-bit all over again.

For what it's worth, I fully agree with Colin that some of Joe Testa's
recommended hardening measures lack proper justification. Damien
Miller noticed the same thing, when I recently asked him to comment on
the recommendations.

I however think that Daniel's proposal for a patch that better takes
into consideration possible local deviations from Debian defaults
might be a good compromise between adopting 'ssh-audit' paranoia for
the Debian package and letting administrators adopt them if they wish.

Martin-Éric

I'm wary of adding too much complexity there, but I'd at least consider
such patches.

That's about DH moduli rather than host key sizes, right?  That feels
somewhat different, because we just ship upstream's moduli file as a
conffile, so providing any debconf-style control over that would be very
difficult to do in a policy-compliant way.  (I'm also not sure what the
compatibility implications are of dropping the smaller primes; I assume
there must be some or upstream would probably have done it already ...)

Are those comments somewhere public so that I can look at them?

Thanks,

Also, in https://bugzilla.mindrot.org/show_bug.cgi?id=2793#c1, Damien
Miller wrote:

  ... I don't think making people edit the moduli file is a great way to
  control which groups are negotiated. IMO a general MinimumDHSize
  option would probably be a better way to achieve this.

I tend to agree, so I think any effort in the direction of giving people
packaged ways to filter the moduli file (or whatever) would be better
directed towards adding something like MinimumDHSize upstream.  Then
that ssh-audit recommendation could just become adding a single line to
/etc/ssh/sshd_config.d/ssh-audit_hardening.conf.

su 26.1.2025 klo 20.09 Colin Watson (cjwatson@debian.org) kirjoitti:

openssh-server: /etc/ssh/moduli

In principle, this is in the /etc hierarchy, so it should be possible
to treat it like a config and explicitly skip overwriting it with a
debconf question, if we have modified the file such as by removing low
primes.

No, I just directly e-mailed Damien asking him whether he agreed with
the recommendations 'ssh-audit' makes. He wasn't aware of the
existence of the tool or the hardening guide. His initial impression
was that some recommendations are perplexing. For instance, he doesn't
understand Joe's recommendation against ECDH kex being justified by
"heavy suspicion in the community that it is backdoored by a 3-letter
agency."

Martin-Éric

Not without migrating it away from being a dpkg-managed conffile, which
introduces a considerable amount of maintainer script complexity.

debconf questions (or any other kind of maintainer-script-driven changes
to configuration files) cannot coexist gracefully with dpkg management
of conffiles.  They only work with non-dpkg-managed configuration files.

Yeah, at this point I'm not inclined to treat ssh-audit as having any
special authority.  It's mostly just one person's recommendations, which
may or may not be good on their own individual merits - but I don't
intend to accept it as a target to work towards in general.

I'd also like to say that I think some of ssh-audit's recommendations
are harmful to some extent.  In particular the first of the following
issues looks as though it'll cause me some problems in the forky cycle.
This makes me reluctant to give it any more prominence than it already
has.

https://github.com/jtesta/ssh-audit/issues/324
https://github.com/jtesta/ssh-audit/issues/325