Re: Stronger ssh settings

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)

--=_5b2e26e4659c43353769a66f8b928d1a
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII;
 format=flowed

Am 2026-04-05 16:09, schrieb Christian Weisgerber:
> Alexander Leidinger:
> 
>> I propose to extend our ssh config (and maybe other configs) regarding
>>  - settings for government standards
>>  - improved FreeBSD defaults
> 
> Upstream OpenSSH has a history of walking a good compromise line
> between phasing out aging algorithms and maintaining compatibility
> with most of the installed base.  I don't think FreeBSD can improve
> on those defaults.

There was a timeframe where we still had algorithms enabled which 
OpenSSH disabled a bit late (at least to my opinion). OpenSSH has to 
take their complete userbase into account, we could have the luxury to 
limit that to our supported FreeBSD versions for at least the sshd 
config.

> Government standards may require disabling some of the algorithms
> OpenSSH prefers.  That is more likely a disimprovement.  Anyway,

I don't disagree, but in some cases there is no option than to comply.

> if people would like example configurations compliant with FIPS or
> such, I don't object.
> 
>> (I simply included what I use on my systems, and they
>> should work for connections from and to all supported FreeBSD releases 
>> as I
>> have them like that since a long time; an alternative would be to use 
>> the
>> exclude syntax instead).
> 
> Algorithm lists have the habit of going stale.  They would have to
> be carefully reviewed each time OpenSSH is updated.  Unless a
> definitive list is required, using the +/- syntax to prefer/disable
> algorithms is frequently a better choice.
> 
>> +### FreeBSD ###
>> +HostKeyAlgorithms rsa-sha2-512,rsa-sha2-256,ssh-ed25519
> 
> Why do you drop ECDSA and all CA algorithms?
> 
>> +KexAlgorithms 
>> [email protected],curve25519-sha256,[email protected],diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256
> 
> Why do you drop the standard name "sntrup761x25519-sha512"?
> More importantly, who do you drop mlkem768x25519-sha256, which is the
> upstream default?
> Let me guess, this list is a few years old and has gone stale.

Yes, as noted. This is OK for where I copied it from. This is not what I 
propose. As noted I copied that there to discuss this in concept, not 
those particular options. Shawn Webb has put some other options into 
this dicussion. From one POV I agree with those, and at the same time 
from another POV I disagree about those. Before talking about particular 
options, there should be first a consensus if we are OK to differ, and 
about the goal of the difference (what shall be our target?). Only then 
we can really talk about particular options.

> I think "improved FreeBSD defaults" are a bad idea.

In the sense of "we shall not differ", or in regards of tgose particular 
options?

Bye,
Alexander.

-- 
http://www.Leidinger.net [email protected]: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    [email protected]  : PGP 0x8F31830F9F2772BF

--=_5b2e26e4659c43353769a66f8b928d1a
Content-Type: application/pgp-signature;
 name=signature.asc
Content-Disposition: attachment;
 filename=signature.asc;
 size=833
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmnUvOAACgkQEg2wmwP4
2IbLDg/9FVupvn/XGeWEwlkO78mPK222n8L1WeATsBhbEOhHCJEtuVWX/SWo12n/
ujSFAx+QaZrZn/wqSSq8F/IiMW1TEYtL1OyTe+DLOAOLq4JfWLR9Bl7f+Jkt94GP
n83zuwiy2ttqJpK6dqEWXyePp8MnJP8o7exDr9UV1KZt+VM/yhDbJ6oKGtrMWnUL
mlwQtqYBFazYHoxoK57kbuXfio+0U8NmvKKs717BVq2q9EyhGV4ni+Zj+v01Ph2S
6Ev/2rRoRK+oT0TMAGMg3u+xVztLd9KdAqha6/VhCjgGHYvqt7LL0vHwEeSxW+Ka
LLyt5iLssEilHfuXfQdwk4J692NYgPPmi42eJTkHWIoqvhLM+KVE7mUmMUC3KF/3
scbFXyNrhtDkq54dYPW0EdFn2SpgAlyDRkicW75Pbez0t9Mu8zN7NlXJ7t9Dr43y
A19U6KHd7yq3bkwpH7lCdSX50pfhMsGzR63/ZichZJHVx/fjvZvsU1FDy+Ibfvf4
Fm7cnnA8H/ZdUuZtLdvn6LQA81yXwVum/49jxOK3CL2E2hyIElkkyKzjJg7pU9DR
CsVDXGHSXsIq1H0sIAdKHTOQN376sEoLhQhktM09JMgt+K+epgWLxo5Hy4CCTCZS
uM+1jwseG9SQB/8EnmzCQWTIZ4IyHOeZ3qek5Xy7ABQ9aA6JGw0=
=dKxF
-----END PGP SIGNATURE-----

--=_5b2e26e4659c43353769a66f8b928d1a--