fe873a1c10
next round of patches - allow X forwarding over IPv4 when IPv6 sockets is not available [openssh-7.2p2-X_forward_with_disabled_ipv6.patch] - do not write PID file when not daemonizing [openssh-7.2p2-no_fork-no_pid_file.patch] - use correct options when invoking login [openssh-7.2p2-login_options.patch] - helper application for retrieving users' public keys from an LDAP server [openssh-7.2p2-ldap.patch] - allow forcing permissions over sftp [openssh-7.2p2-sftp_force_permissions.patch] - do not perform run-time checks for OpenSSL API/ABI change [openssh-7.2p2-disable-openssl-abi-check.patch] - suggest commands for cleaning known hosts file [openssh-7.2p2-host_ident.patch] - sftp home chroot patch [openssh-7.2p2-sftp_homechroot.patch] - ssh sessions auditing [openssh-7.2p2-audit.patch] - enable seccomp sandbox on additional architectures [openssh-7.2p2-additional_seccomp_archs.patch] OBS-URL: https://build.opensuse.org/request/show/432093 OBS-URL: https://build.opensuse.org/package/show/network/openssh?expand=0&rev=112
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.
|
|
|