Go to main content

Managing Secure Shell Access in Oracle® Solaris 11.3

Exit Print View

Updated: October 2019

About Secure Shell

Secure Shell is the active remote access protocol on a newly installed Oracle Solaris system. The default implementation of Secure Shell is the sunssh implementation (SunSSH). The openssh implementation (OpenSSH) is also available.

SunSSH uses low-level cryptography APIs from the OpenSSL libcrypto library. The OpenSSL toolkit implements the Secure Sockets Layer and Transport Layer Security. To display the version of OpenSSL, run the openssl version command in a terminal window.

Note -  OpenSSL can implement FIPS 140-2, a U.S. government computer security standard for cryptography modules. See OpenSSH and FIPS 140-2 and SunSSH and FIPS 140-2.

In Secure Shell, authentication is provided by the use of passwords, public keys, or both. All network traffic is encrypted. Thus, Secure Shell prevents a would-be intruder from being able to read an intercepted communication. Secure Shell also prevents an adversary from spoofing the system.

Secure Shell can also be used as an on-demand virtual private network (VPN). A VPN can forward X Window system traffic or can connect individual port numbers between the local systems and remote systems over an encrypted network link.

    With Secure Shell, you can perform these actions:

  • Log in to another host securely over an unsecured network.

  • Copy files securely between the two hosts.

  • Run commands securely on the remote system.

On the server side, Secure Shell supports version 2 (v2) of the Secure Shell protocol. On the client side, in addition to v2, the client supports version 1 (v1).

Secure Shell Authentication

Secure Shell provides public key and password methods for authenticating the connection to the remote system. Public key authentication is a stronger authentication mechanism because the private key never travels over the network.

    The authentication methods are tried in the following order. When the configuration does not satisfy an authentication method, the next method is tried.

  • GSS-API authentication – Uses credentials for GSS-API mechanisms such as mech_krb5 (Kerberos V) to authenticate Secure Shell clients and servers. For more information about GSS-API authentication, see Introduction to GSS-API in Developer’s Guide to Oracle Solaris 11.3 Security.

  • Host-based authentication – Uses host keys and rhosts files. Uses the Secure Shell client's RSA or DSA public/private host keys to authenticate the client. Uses the files. Uses the client's RSA or DSA public/private host keys to authenticate the client. Uses the rhosts files to authorize clients to users.

  • Public key authentication – Authenticates users with their RSA or DSA public/private keys.

  • Keyboard-interactive authentication – Uses PAM to authenticate users. Keyboard authentication method in v2 allows for arbitrary prompting by PAM. For more information, see the SECURITY section in the sshd(1M) man page.

The following table shows the requirements for authenticating a user who is trying to log into a remote system. The user is on the local system, the client system. The remote system, the Secure Shell server, is running the sshd daemon. The table shows the Secure Shell authentication methods and the system requirements.

Table 1  Authentication Methods for Secure Shell
Secure Shell Authentication Method
Local Host (Client) Requirements
Remote Host (Server) Requirements
Initiator credentials for the GSS mechanism.
Acceptor credentials for the GSS mechanism. For more information, see Acquiring GSS Credentials in Secure Shell.
User account
Local host private key in /etc/ssh/ssh_host_rsa_key or /etc/ssh/ssh_host_dsa_key
HostbasedAuthentication yes in /etc/ssh/ssh_config
User account
Local host public key in /etc/ssh/known_hosts or ~/.ssh/known_hosts
HostbasedAuthentication yes in /etc/ssh/sshd_config
IgnoreRhosts no in /etc/ssh/sshd_config
Local host entry in /etc/ssh/shosts.equiv, /etc/hosts.equiv, ~/.rhosts, or ~/.shosts
User account
User account
Supports PAM.
RSA or DSA public key
User account
Private key in ~/.ssh/id_rsa or ~/.ssh/id_dsa
User's public key in ~/.ssh/id_rsa.pub or ~/.ssh/id_dsa.pub
User account
User's public key in ~/.ssh/authorized_keys
X.509 public key certificates
User certificates
HostKey pointer to certificate URI
Policy in /etc/ssh/policy.xml
PIN file in etc/ssh/pinfile
KMF Policy
HostKey pointer to certificate URI
Policy in /etc/ssh/policy.xml
Certificates in /etc/ssh/cert, OpenSSL keystore, or PKCS #11 keystore