Marcus Meissner
3f6eda5c88
* No changes for askpass, see main package changelog for
details.
- Update to openssh 9.9p1:
= Future deprecation notice
* OpenSSH plans to remove support for the DSA signature algorithm
in early 2025. This release disables DSA by default at compile
time. DSA, as specified in the SSHv2 protocol, is inherently
weak - being limited to a 160 bit private key and use of the
SHA1 digest. Its estimated security level is only 80 bits
symmetric equivalent.
OpenSSH has disabled DSA keys by default since 2015 but has
retained run-time optional support for them. DSA was the only
mandatory-to-implement algorithm in the SSHv2 RFCs, mostly
because alternative algorithms were encumbered by patents when
the SSHv2 protocol was specified.
This has not been the case for decades at this point and better
algorithms are well supported by all actively-maintained SSH
implementations. We do not consider the costs of maintaining
DSA in OpenSSH to be justified and hope that removing it from
OpenSSH can accelerate its wider deprecation in supporting
cryptography libraries.
= Potentially-incompatible changes
* ssh(1): remove support for pre-authentication compression.
OpenSSH has only supported post-authentication compression in
the server for some years. Compression before authentication
significantly increases the attack surface of SSH servers and
risks creating oracles that reveal information about
information sent during authentication.
OBS-URL: https://build.opensuse.org/package/show/network/openssh?expand=0&rev=275
65 lines
3.2 KiB
Plaintext
65 lines
3.2 KiB
Plaintext
Notes on FIPS mode and OpenSSH
|
|
|
|
---
|
|
|
|
SUSE OpenSSH comes with FIPS 140-2 support, and certain versions have been
|
|
certified as FIPS compliant by NIST. Apart from other things, this standard
|
|
puts restrictions on cryptographic algorithms that may be used.
|
|
|
|
Important notice: FIPS is not only a matter of functionality. If you want to
|
|
claim having a FIPS certified service, you *must* use the certified binaries.
|
|
Even binaries built from the same sources in the same environment and running
|
|
on a certified system, yet from a package lacking the certification, are
|
|
formally not considered to be fulfilling the requirements.
|
|
|
|
The certified binaries (ssh, sshd, sftp-server) perform mandatory selfcheck at
|
|
startup and proceed only when the checks succeed (non-certified binaries may
|
|
skip the check). These checks require the cryptographic hashes contained in the
|
|
openssh-fips subpackage.
|
|
|
|
The FIPS mode for OpenSSH is enabled in two ways - either:
|
|
|
|
1) /proc/sys/crypto/fips_enabled contains a single character '1' - this is a
|
|
system-wide setting controlled bu the fips kernel parameter; or
|
|
|
|
2) the environment variable SSH_FORCE_FIPS - if set (to any value), the
|
|
binaries behave as if they were running on a system in FIPS mode.
|
|
|
|
Since FIPS 140-2 only allows use of certain cryptographic algorithms, both the
|
|
client and server will fail if they are requested to use non-approved
|
|
algorithms while in FIPS mode. This means that working configurations for FIPS
|
|
mode form a proper subset of all working (generic) configurations. Some
|
|
configurations may even prevent the binaries from starting at all.
|
|
|
|
This however should be viewed in the context of FIPS being a security policy
|
|
tool - it is not of much use to run the same system both in FIPS mode and
|
|
outside of it, since that would defeat the main purpose of FIPS having
|
|
guaranteeing standardised minimum restrictions on cryptographic algorithms
|
|
(and thus on the overall security of the system).
|
|
|
|
Unless you specify what cryptographic algorithms you wish to use, both the
|
|
client and server should work out of the box in FIPS mode.
|
|
|
|
For sshd, you can use the `-t` option to check whether the configuration file
|
|
is working. Setting the above mentioned environment variable allows testing of
|
|
behaviour in FIPS mode (checksum files for both OpenSSH and OpenSSL must be
|
|
installed).
|
|
|
|
In addition to cryptographic algorithms restrictions, sshd performs periodic
|
|
PRNG re-seeding. The seed is read from entropy source either /dev/urandom or
|
|
/dev/random. By default, the former is used, unless the environment variable
|
|
SSH_USE_STRONG_RNG is set to a non-zero value or the binary is running in FIPS
|
|
mode. This has two important implications:
|
|
|
|
1) the selected entropy source must be available, i.e. when running in a
|
|
changeroot the device files need to be present there.
|
|
|
|
2) /dev/random is a blocking interface - unless enough randomness is available,
|
|
the process stops until the entropy pool is replenished. Thus on systems where
|
|
a long running processes are expected, one should make sure there is always
|
|
enough entropy for sshd. Sporadically this may also cause sshd to aborted,
|
|
since some versions of OpenSSL (the underlying cryptographic engine) don't
|
|
handle gracefully being interrupted while trying to read entropy from the
|
|
system source.
|
|
|