Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Mail Systems
Eclipse Documentation

How To Guides
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Problem Solutions
Privacy Policy




System Administration Guide: Security Services
Previous Next

Solaris Secure Shell (Overview)

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

Solaris 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 machines and remote machines over an encrypted network link.

With Solaris 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 host.

Solaris Secure Shell supports two versions of the Secure Shell protocol. Version 1 is the original version of the protocol. Version 2 is more secure, and it amends some of the basic security design flaws of version 1. Version 1 is provided only to assist users who are migrating to version 2. Users are strongly discouraged from using version 1.

Note - Hereafter in this text, v1 is used to represent version 1, and v2 is used to represent version 2.

Solaris Secure Shell Authentication

Solaris Secure Shell provides public key and password methods for authenticating the connection to the remote host. Public key authentication is a stronger authentication mechanism than password authentication, 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 – Uses credentials for GSS-API mechanisms such as mech_krb5 (Kerberos V) and mech_dh (AUTH_DH) to authenticate clients and servers. For more information on GSS-API, see Introduction to GSS-API in Solaris Security for Developers Guide.

  • Host-based authentication – Uses host keys and rhosts files. Uses the client's RSA and 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 and DSA public/private keys.

  • Password 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 host. The user is on the local host, the client. The remote host, the server, is running the sshd daemon. The table shows the Solaris Secure Shell authentication methods, the compatible protocol versions, and the host requirements.

Table 19-1 Authentication Methods for Solaris Secure Shell

Authentication Method (Protocol Version)

Local Host (Client) Requirements

Remote Host (Server) Requirements

GSS-API (v2)

Initiator credentials for the GSS mechanism.

Acceptor credentials for the GSS mechanism. For more information, see Acquiring GSS Credentials in Solaris Secure Shell.

Host-based (v2)

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

RSA or DSA public key (v2)

User account

Private key in ~/.ssh/id_rsa or ~/.ssh/id_dsa

User's public key in ~/.ssh/ or ~/.ssh/

User account

User's public key in ~/.ssh/authorized_keys

RSA public key (v1)

User account

Private key in ~/.ssh/identity

User's public key in ~/.ssh/

User account

User's public key in ~/.ssh/authorized_keys

Keyboard-interactive (v2)

User account

User account

Supports PAM, including arbitrary prompting and password changing when password aging is triggered.

Password-based (v1 or v2)

User account

User account

Supports PAM.

.rhosts only (v1)

User account

User account

IgnoreRhosts no in /etc/ssh/sshd_config

Local host entry in /etc/ssh/shosts.equiv, /etc/hosts.equiv, ~/.shosts, or ~/.rhosts

.rhosts with RSA (v1) on server only

User account

Local host public key in /etc/ssh/ssh_host_rsa1_key

User account

Local host public key in /etc/ssh/ssh_known_hosts or ~/.ssh/known_hosts

IgnoreRhosts no in /etc/ssh/sshd_config

Local host entry in /etc/ssh/shosts.equiv, /etc/hosts.equiv, ~/.shosts, or ~/.rhosts

Solaris Secure Shell in the Enterprise

For a comprehensive discussion of Secure Shell on a Solaris system, see Secure Shell in the Enterprise, by Jason Reid, ISBN 0-13-142900-0, June 2003. The book is part of the Sun BluePrints Series, which is published by Sun Microsystems Press.

For online information, navigate to Sun's BigAdmin System Administration Portal web site, Click Docs, then Sun BluePrints under Misc./Comprehensive. Click Sun BluePrints OnLine, then Archives by Subject, then Security. The archives include the following articles:

  • Role Based Access Control and Secure Shell – A Closer Look At Two Solaris Operating Environment Security Features

  • Integrating the Secure Shell Software

  • Configuring the Secure Shell Software

Previous Next

  Published under the terms fo the Public Documentation License Version 1.01. Design by Interspire