File README.FIPS of Package openssh.17033

Overview Repositories Revisions Requests Users Attributes Meta

File README.FIPS of Package openssh.17033

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.

Places

File README.FIPS of Package openssh.17033

Places