Managing Secure Shell Access in Oracle® Solaris 11.2

Exit Print View

Updated: September 2014

Secure Shell and FIPS 140

Secure Shell is a consumer of the OpenSSL FIPS 140 module. Oracle Solaris provides a FIPS 140 option for the server side and the client side. To comply with FIPS 140 requirements, administrators should configure and use the FIPS 140 options.

FIPS mode, where Secure Shell uses the FIPS 140 mode of OpenSSL, is not the default. As the administrator, you must explicitly enable Secure Shell to run in FIPS 140 mode. You can invoke FIPS 140 mode with the command ssh -o "UseFIPS140 yes" remote-host. As an alternative, you can set a keyword in the configuration files.

    Briefly, the implementation consists of the following:

  • The following FIPS 140-approved ciphers are available on the server and client side: aes128-cbc, aes192-cbc, and aes256-cbc.

    3des-cbc is available by default on the client side, but it is not in the server-side cipher list because of potential security risks.

  • The following FIPS 140-approved Message Authentication Codes (MAC) are available:

    • hmac-sha1, hmac-sha1-96

    • hmac-sha2-256, hmac-sha2-256-96

    • hmac-sha2-512, hmac-sha2-512-96

  • Four server-client configurations are supported:

    • No FIPS 140 mode on either the client or server side

    • FIPS 140 mode on both the client and server side

    • FIPS 140 mode on the server side but no FIPS on the client side

    • No FIPS 140 mode on the server side but FIPS mode on the client side

  • The ssh-keygen command has an option to generate the user's private key in the PKCS #8 format that Secure Shell clients in FIPS mode require. For more information, see the ssh-keygen(1) man page.

For more information about FIPS 140, see Using a FIPS 140 Enabled System in Oracle Solaris 11.2 . See, also, the sshd(1M), sshd_config(4), ssh(1), and ssh_config(4) man pages.

When you use a Sun Crypto Accelerator 6000 card for Secure Shell operations, Secure Shell runs with FIPS 140 support at Level 3. Level 3 hardware is certified to resist physical tampering, use identity-based authentication, and isolate the interfaces that handle critical security parameters from the hardware's other interfaces.