Go to main content

Managing Secure Shell Access in Oracle® Solaris 11.4

Exit Print View

Updated: June 2019
 
 

OpenSSH Implementation of Secure Shell

In this Oracle Solaris release, openssh is the only available 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. The /network/ssh:default SMF service runs the OpenSSH implementation of Secure Shell.

Oracle Solaris Modifications to OpenSSH

To see which version of the OpenSSH project is the basis for OpenSSH on your system, run the pkg info openssh command. Oracle Solaris engineers have modified the man pages to include Oracle Solaris changes, so use the man command to view Secure Shell man pages in Oracle Solaris. Do not use the man pages from the OpenSSH project.

    Oracle Solaris differences from the OpenSSH project include the following:

  • Secure Shell protocol version 1 (v1) is not supported on the client.

    If you have network entities that support only v1, such as old network routers, you can no longer connect to such devices. However, Oracle Solaris legacy releases, such as Oracle Solaris 10 and Oracle Solaris 11.3 can use SunSSH to access systems that use v1.

  • Oracle Solaris removed unsafe algorithms from OpenSSH. To view which ciphers, MACs, and key exchange algorithms are supported, list them with the following commands:

    $ ssh -Q cipher
    $ ssh -Q mac
    $ ssh -Q kex

    The sshd_config (5) and ssh_config (5) man pages list the supported algorithms.

    If you are using or connecting with systems that use deprecated or removed algorithms, see Using OpenSSH with Legacy SSH Implementations.

  • Oracle Solaris stores delegated credentials in a default credential cache such as /tmp/krb5cc_101. Credentials in a default credential cache can be used for accessing NFS file systems protected by Kerberos. To configure this setting, see Per-Session GSS-API Credentials.

    In contrast, the OpenSSH project stores delegated credentials in a non-default credential cache such as /tmp/krb5cc_101_WO4082.

    For more information, see Trusted Delegated Services in Kerberos in Managing Kerberos in Oracle Solaris 11.4. Also, use the man command to view the sshd_config (5) and ssh_config (5) man pages.

  • Oracle Solaris provides an LDAP schema and helper application to enable ssh to get a user's public key from an LDAP keystore. For more information, see Secure Shell and Remote Public Keys.

Transition From SunSSH to OpenSSH

    For users familiar with SunSSH, note the following differences from OpenSSH.

  • OpenSSH contains keywords that SunSSH did not.

    ## sshd_config file
    ...
    KexAlgorithms
  • Unlike SunSSH, OpenSSH is not compiled with TCP wrappers. To configure OpenSSH to handle the function of TCP wrappers, see Replacing TCP Wrappers With sshd_config Entries.

  • Unlike SunSSH, OpenSSH supports only the PATH variable from a user's login shell. OpenSSH does not use the values from the /etc/default/login file, even when the sshd_config file does not set the equivalent keywords.

  • OpenSSH does not use X.509 public key certificates. To use public key certificates for Secure Shell authentication, see the CERTIFICATES section in the ssh-keygen(1) man page.

  • The default value of the UseDNS configuration variable is No in OpenSSH.

    Therefore, replace host names with IP addresses in OpenSSH configuration files and commands. Some examples from configuration files include the following:

    ## sshd_config file
    Match Address 192.0.2.10
    AllowUsers jdoe@192.0.2.10
    AllowGroups staff@192.0.2.10
    DenyUsers jsmith@192.0.2.10
    
    ## /etc/ssh/shosts.equiv or /.shosts file 
    192.0.2.10
    
    ## ~/.ssh/authorized_keys file
    from="192.0.2.10" ssh-rsa AAAAB3...Q== jdoe@192.0.2.11

Replacing TCP Wrappers With sshd_config Entries

OpenSSH does not support TCP wrappers. You can configure a firewall to replace the /etc/hosts.allow and /etc/hosts.deny files. For a sshd_config file solution, see Example 1, Using a Match Block to Allow Logins From a Subnet Only.


Note -  The openssh implementation of Secure Shell continues to use TCP connections. Only the TCP wrapper function, libwrap, is no longer supported.
Example 1  Using a Match Block to Allow Logins From a Subnet Only

In this example, the SunSSH administrator had configured TCP wrappers to allow logins only from the 192.0.2.0/16 subnet.

jdoe-uk:~$ cat /etc/hosts.allow
    sshd : 192.0.
jdoe-uk:~$ cat /etc/hosts.deny
    ALL : ALL 

In OpenSSH, the following entry in the sshd_config file sets an equivalent restriction:

Match Address *,!192.0.2.0/16
            MaxAuthTries 0