Managing Secure Shell Access in Oracle^® Solaris 11.3

OpenSSH Implementation of Secure Shell

OpenSSH in Oracle Solaris is built on the latest version of the OpenSSH project, plus additions that are particular to the Oracle Solaris environment. To see which version of the OpenSSH project is the basis for OpenSSH on your system, run the pkg info openssh command.

Although SunSSH is the default, you can switch to the new OpenSSH implementation. You can use only one implementation at a time.

Oracle Solaris Modifications to OpenSSH

Oracle Solaris makes the following changes to OpenSSH:

• SunSSH Keywords Are Deprecated in OpenSSH

• Secure Shell Protocol 1 Support Is Removed

• Unsafe Algorithms Are Removed From OpenSSH

• diffie-hellman-group1-sha1 Is Disabled by Default

• ssh-dss Keys Are Disabled by Default

• Default Value of UseDNS Is No in OpenSSH

• TCP Wrappers Are Not Supported in OpenSSH

SunSSH Keywords Are Deprecated in OpenSSH

To ease the transition from SunSSH to OpenSSH, SunSSH-only options are available but deprecated in OpenSSH. OpenSSH ignores a deprecated option.

Deprecated server options include the following:

       GSSAPIStoreDelegatedCredentials
       GSSStoreDelegCreds
       KMFPolicyDatabase
       KMFPolicyName
       LookupClientHostnames
       MaxAuthTriesLog
       PreUserauthHook
       TrustedAnchorKeystore
       UseFIPS140
       UseOpenSSLEngine
       UseUnsupportedSshv1

Deprecated client options include the following:

       KMFPolicyDatabase
       KMFPolicyName
       TrustedAnchorKeystore
       UseFIPS140
       UseOpenSSLEngine

Secure Shell Protocol 1 Support Is Removed

Secure Shell Protocol 1 (v1) support is absent from OpenSSH on both the server side and the client side. If you have network entities that support only v1, such as old network routers, you can no longer connect to such devices by using OpenSSH. However, Oracle Solaris 10 users can still use SunSSH to access systems that use v1. And, Oracle Solaris 11.3 users can still use SunSSH to access systems that use v1.

Unsafe Algorithms Are Removed From OpenSSH

The default set of ciphers and MACs has been altered to remove unsafe algorithms. You can use the following commands to list all supported ciphers and MACs:

$ ssh -Q cipher
$ ssh -Q mac

For more information, see the sshd_config(4) and ssh_config(4) man pages.

diffie-hellman-group1-sha1 Is Disabled by Default

Because the diffie-hellman-group1-sha1 key exchange is no longer considered secure, it is disabled on both the Secure Shell client and server sides.

If your servers support only diffie-hellman-group1-sha1, you should upgrade them to support diffie-hellman-group-exchange-sha256. Or, as a second choice, upgrade Oracle Solaris to a version which supports diffie-hellman-group14-sha1.

If upgrading the peer is not an option, users connecting to systems that do not support diffie-hellman-group-exchange-sha256, diffie-hellman-group14-sha1, or diffie-hellman-group-exchange-sha1 can enable diffie-hellman-group1-sha1 as follows:

# ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 user@system1

For the OpenSSH implementation of Secure Shell, the server administrator can allow logins from systems that do not support secure key exchange methods by explicitly enabling insecure key exchange methods. Add this line to the /etc/ssh/sshd_config file.

KexAlgorithms
diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group-exchange-sha256

Then, restart the ssh SMF service on the server.

ssh-server# svcadm restart ssh

For additional information, see Using OpenSSH with Legacy SSH Implementations.

ssh-dss Keys Are Disabled by Default

Because the ssh-dss and ssh-dss-cert-* host and user key types are inherently weak, they are disabled by default at run time.

If you have been using ssh-dss keys for public key authentication, you should create new ssh-rsa keys and remove existing ssh-dss keys from all authorized_keys files. For instructions about creating new keys, see How to Generate a Public/Private Key Pair for Use With Secure Shell.

If ssh-rsa and ssh-dss host keys are not already present, svc:/network/ssh:default creates both. So, Oracle Solaris servers usually have ssh-dss host keys and ssh-rsa keys. In the rare cases where servers were provisioned with only an ssh-dss host key, you should add a ssh_rsa host key. If you cannot create the key, then the user needs to enable the ssh-dss key type on the command line to connect to the server by running the following command:

# ssh -oHostKeyAlgorithms=+ssh-dss user@somehost

For additional information, see Using OpenSSH with Legacy SSH Implementations.

Default Value of UseDNS Is No in OpenSSH

If no UseDNS value is specified in the sshd_config file, the default value of UseDNS is No. The former default value provided no security benefit.

A UseDNS value of No means that you cannot use host names when configuring an ssh service.

You have two options:

• You can explicitly specify UseDNS yes in the sshd_config file.

• You can use IP addresses instead of host names in the sshd_config file as shown in the following examples.

  • In the Match block section of the sshd_config file, use an Address criterion instead of a Host criterion.

    For example, you would replace Match Host somehost.domain with Match Address 192.0.2.11.

  • In the sshd_config entries for AllowUsers, AllowGroups, DenyUsers, and DenyGroups, use an IP address instead of the host name.

    For example, you would replace AllowUsers jsmith@somehost.domain with AllowUsers jsmith@192.0.2.11.

  • In /etc/ssh/shosts.equiv or ~/.shosts entries, use an IP address instead of a host name.

    For example, you would replace somehost.domain with 192.0.2.11.

  • In the ~/.ssh/authorized_keys entry, use an IP address instead of a host name when specifying the from option.

    For example, you would replace from="somehost.domain" ssh-rsa AAAAB3...Q== jsmith@work with from="192.0.2.11" ssh-rsa AAAAB3...Q== jsmith@work.

TCP Wrappers Are Not Supported in OpenSSH

OpenSSH does not support TCP wrappers. You will need to modify the sshd_config file or use a firewall to preserve a configuration that was previously enforced by TCP wrappers.

If you have been using TCP wrappers, you have been using /etc/hosts.allow or /etc/hosts.deny to allow or deny logins. Use the Match block in the sshd_config file to set up an equivalent configuration.

For example, to allow logins only from the 192.0.2.0/16 subnet, you might have set up TCP wrappers as follows:

root@jsmith-cz:~# cat /etc/hosts.allow
    sshd : 192.0.
    root@jsmith-cz:~# cat /etc/hosts.deny
    ALL : ALL 

The following entry in the sshd_config file sets an equivalent restriction:

Match Address *,!192.0.2.0/16
            MaxAuthTries 0

Another option is to configure a firewall for access control. Settings similar to these examples can be enforced by a firewall. Firewall access control occurs before the network connection is established in the kernel.

Oracle Solaris Additions to OpenSSH

OpenSSH is an optional package, openssh, that you can install on your system. Although features have been added to the openssh implementation, it remains compatible with the OpenSSH project.

The following Oracle Solaris features have been added to the openssh implementation:

• DisableBanner keyword – disables the display of a banner message from the Secure Shell client. For more information, see the ssh_config (4) man page.

• PAM support – PAMServiceName and PAMServicePrefix keywords are available in the openSSH implementation.

• Auditing support – OpenSSH generates Oracle Solaris audit records for login and logout.

• Xforwarding – Is functional with non-writable home directories.

• Proxy commands – For SOCKS5 and HTTP protocols work in SunSSH and in OpenSSH. For an example, see How to Set Up Default Secure Shell Connections to Hosts Outside a Firewall. The netcat utility provides similar functionality.

• GSSAPI-Authenticated Diffie-Hellman Key Exchange – Is implemented as specified in RFC 4462.

• Role login – Is implemented for host-based authentication if properly configured in PAM and sshd.

Delegated credentials in OpenSSH are stored differently on Oracle Solaris than the credentials are stored on other platforms.

• Unlike the OpenSSH project, which stores delegated credentials in a non-default credential cache such as /tmp/krb5cc_101_WO4082, the openssh implementation of Secure Shell uses a default credential cache such as /tmp/krb5cc_101.

• Credentials in a default credential cache can be used to access NFS file systems that are protected by Kerberos.

  For more information, see Managing Kerberos and Other Authentication Services in Oracle Solaris 11.3.

• OpenSSH can run in FIPS 140-2 mode.

  For more information, see OpenSSH and FIPS 140-2.

OpenSSH and FIPS 140-2

Unlike SunSSH, OpenSSH enables FIPS 140-2 mode dynamically. If the OpenSSL library that OpenSSH links with is FIPS 140-2 capable, OpenSSH runs in FIPS 140-2 mode.

See Example of Running in FIPS 140-2 Mode on an Oracle Solaris 11.3 SRU 5.6 System in Using a FIPS 140-2 Enabled System in Oracle Solaris 11.3.