System Administration Guide: Security Services

Chapter 20 Solaris Secure Shell (Reference)

This chapter describes the configuration options in Solaris Secure Shell. The following is a list of the reference information in this chapter.

For procedures to configure Solaris Secure Shell, see Chapter 19, Using Solaris Secure Shell (Tasks).

A Typical Solaris Secure Shell Session

The Solaris Secure Shell daemon (sshd) is normally started at boot time when network services are started. The daemon listens for connections from clients. A Solaris Secure Shell session begins when the user runs an ssh, scp, or sftp command. A new sshd daemon is forked for each incoming connection. The forked daemons handle key exchange, encryption, authentication, command execution, and data exchange with the client. These session characteristics are determined by client-side configuration files and server-side configuration files. Command-line arguments can override the settings in the configuration files.

The client and server must authenticate themselves to each other. After successful authentication, the user can execute commands remotely and copy data between hosts.

Session Characteristics in Solaris Secure Shell

The server-side behavior of the sshd daemon is controlled by keyword settings in the /etc/ssh/sshd_config file. For example, the sshd_config file controls which types of authentication are permitted for accessing the server. The server-side behavior can also be controlled by the command-line options when the sshd daemon is started.

The behavior on the client side is controlled by Solaris Secure Shell keywords in this order of precedence:

Command-line options
User's configuration file, ~/.ssh/config
System-wide configuration file, /etc/ssh/ssh_config

For example, a user can override a system-wide configuration Ciphers setting that prefers aes128–ctr by specifying -c aes256–ctr,aes128-ctr,arcfour on the command line. The first cipher, aes256–ctr, is now preferred.

Authentication and Key Exchange in Solaris Secure Shell

The Solaris Secure Shell protocols, v1 and v2, both support client user/host authentication and server host authentication. Both protocols involve the exchange of session cryptographic keys for the protection of Solaris Secure Shell sessions. Each protocol provides various methods for authentication and key exchange. Some methods are optional. Solaris Secure Shell supports a number of client authentication mechanisms, as shown in Table 19–1. Servers are authenticated by using known host public keys.

For the v1 protocol, Solaris Secure Shell supports user authentication with passwords. The protocol also supports user public keys and authentication with trusted host public keys. Server authentication is done with a host public key. For the v1 protocol, all public keys are RSA keys. Session key exchanges involve the use of an ephemeral server key that is periodically regenerated.

For the v2 protocol, Solaris Secure Shell supports user authentication and generic interactive authentication, which usually involves passwords. The protocol also supports authentication with user public keys and with trusted host public keys. The keys can be RSA or DSA. Session key exchanges consist of Diffie-Hellman ephemeral key exchanges that are signed in the server authentication step. Additionally, Solaris Secure Shell can use GSS credentials for authentication.

Acquiring GSS Credentials in Solaris Secure Shell

To use GSS-API for authentication in Solaris Secure Shell, the server must have GSS-API acceptor credentials and the client must have GSS-API initiator credentials. Support is available for mech_dh and for mech_krb5.

For mech_dh, the server has GSS-API acceptor credentials if root has run the keylogin command.

For mech_krb5, the server has GSS-API acceptor credentials when the host principal that corresponds to the server has a valid entry in /etc/krb5/krb5.keytab.

The client has initiator credentials for mech_dh if one of the following has been done:

The keylogin command has been run.
The pam_dhkeys module is used in the pam.conf file.

The client has initiator credentials for mech_krb5 if one of the following has been done:

The kinit command has been run.
The pam_krb5 module is used in the pam.conf file.

For the use of mech_dh in secure RPC, see Chapter 16, Using Authentication Services (Tasks). For the use of mech_krb5, see Chapter 21, Introduction to the Kerberos Service. For more information on mechanisms, see the mech(4) and mech_spnego(5) man pages.

Command Execution and Data Forwarding in Solaris Secure Shell

After authentication is complete, the user can use Solaris Secure Shell, generally by requesting a shell or executing a command. Through the ssh command options, the user can make requests. Requests can include allocating a pseudo-tty, forwarding X11 connections or TCP/IP connections, or enabling an ssh-agent authentication program over a secure connection.

The basic components of a user session are as follows:

The user requests a shell or the execution of a command, which begins the session mode.

In this mode, data is sent or received through the terminal on the client side. On the server side, data is sent through the shell or a command.
When data transfer is complete, the user program terminates.
All X11 forwarding and TCP/IP forwarding is stopped, except for those connections that already exist. Existing X11 connections and TCP/IP connections remain open.
The server sends an exit status message to the client. When all connections are closed, such as forwarded ports that had remained open, the client closes the connection to the server. Then, the client exits.

Client and Server Configuration in Solaris Secure Shell

The characteristics of a Solaris Secure Shell session are controlled by configuration files. The configuration files can be overridden to a certain degree by options on the command line.

Client Configuration in Solaris Secure Shell

In most cases, the client-side characteristics of a Solaris Secure Shell session are governed by the system-wide configuration file, /etc/ssh/ssh_config. The settings in the ssh_config file can be overridden by the user's configuration file, ~/.ssh/config. In addition, the user can override both configuration files on the command line.

The settings in the server's /etc/ssh/sshd_config file determine which client requests are permitted by the server. For a list of server configuration settings, see Keywords in Solaris Secure Shell. For detailed information, see the sshd_config(4) man page.

The keywords in the client configuration file are listed in Keywords in Solaris Secure Shell. If the keyword has a default value, the value is given. These keywords are described in detail in the ssh(1), scp(1), sftp(1), and ssh_config(4) man pages. For a list of keywords in alphabetical order and their equivalent command-line overrides, see Table 20–8.

Server Configuration in Solaris Secure Shell

The server-side characteristics of a Solaris Secure Shell session are governed by the /etc/ssh/sshd_config file. The keywords in the server configuration file are listed in Keywords in Solaris Secure Shell. If the keyword has a default value, the value is given. For a full description of the keywords, see the sshd_config(4) man page.

Keywords in Solaris Secure Shell

The following tables list the keywords and their default values, if any. The keywords are in alphabetical order. The location of keywords on the client is the ssh_config file. Keywords that apply to the server are in the sshd_config file. Some keywords are set in both files. If the keyword applies to only one protocol version, the version is listed.

Table 20–1 Keywords in Solaris Secure Shell Configuration Files (A to Escape)


Keyword	Default Value	Location	Protocol
`AllowGroups`	No default.	Server
`AllowTcpForwarding`	`yes`	Server
`AllowUsers`	No default.	Server
`AuthorizedKeysFile`	`~/.ssh/authorized_keys`	Server
`Banner`	`/etc/issue`	Server
`Batchmode`	`no`	Client
`BindAddress`	No default.	Client
`CheckHostIP`	`yes`	Client
`Cipher`	`blowfish`, `3des`	Client	v1
`Ciphers`	`aes128-ctr, aes128-cbc, 3des-cbc, blowfish-cbc, arcfour`	Both	v2
`ClearAllForwardings`	No default.	Client
`ClientAliveInterval`	`0`	Server	v2
`ClientAliveCountMax`	`3`	Server	v2
`Compression`	`yes`	Both
`CompressionLevel`	No default.	Client
`ConnectionAttempts`	`1`	Client
`DenyGroups`	No default.	Server
`DenyUsers`	No default.	Server
`DynamicForward`	No default.	Client
`EscapeChar`	`~`	Client

Table 20–2 Keywords in Solaris Secure Shell Configuration Files (Fall to Local)


Keyword	Default Value	Location	Protocol
`FallBackToRsh`	`no`	Client
`ForwardAgent`	`no`	Client
`ForwardX11`	`no`	Client
`GatewayPorts`	`no`	Both
`GlobalKnownHostsFile`	`/etc/ssh/ssh_known_hosts`	Client
`GSSAPIAuthentication`	`yes`	Both	v2
`GSSAPIDelegateCredentials`	`no`	Client	v2
`GSSAPIKeyExchange`	`yes`	Both	v2
`GSSAPIStoreDelegateCredentials`	`no`	Client	v2
`Host`	`*` For more information, see Host-Specific Parameters in Solaris Secure Shell.	Client
`HostbasedAuthentication`	`no`	Both	v2
`HostbasedUsesNamesFromPacketOnly`	`no`	Server	v2
`HostKey`	`/etc/ssh/ssh_host_key`	Server	v1
`HostKey`	`/etc/ssh/host_rsa_key`, `/etc/ssh/host_dsa_key`	Server	v2
`HostKeyAlgorithms`	`ssh-rsa, ssh-dss`	Client	v2
`HostKeyAlias`	No default.	Client	v2
`IdentityFile`	`~/.ssh/identity`	Client	v1
`IdentityFile`	`~/.ssh/id_dsa, ~/.ssh/id_rsa`	Client	v2
`IgnoreRhosts`	`yes`	Server
`IgnoreUserKnownHosts`	`yes`	Server
`KbdInteractiveAuthentication`	`yes`	Both
`KeepAlive`	`yes`	Both
`KeyRegenerationInterval`	`3600` (seconds)	Server
`ListenAddress`	No default.	Server
`LocalForward`	No default.	Client

Table 20–3 Keywords in Solaris Secure Shell Configuration Files (Login to R)


Keyword	Default Value	Location	Protocol
`LoginGraceTime`	`600` (seconds)	Server
`LogLevel`	`info`	Both
`LookupClientHostname`	`yes`	Server
`MACs`	`hmac-sha1,hmac-md5`	Both	v2
`MaxAuthTries`	`6`	Server
`MaxAuthTriesLog`	3	Server
`MaxStartups`	`10:30:60`	Server
`NoHostAuthenticationForLocalHost`	`no`	Client
`NumberOfPasswordPrompts`	`3`	Client
`PAMAuthenticationViaKBDInt`	`yes`	Server	v2
`PasswordAuthentication`	`yes`	Both
`PermitEmptyPasswords`	`no`	Server
`PermitRootLogin`	`no`	Server
`PermitUserEnvironment`	`no`	Server
`PreferredAuthentications`	`gssapi-keyex, gssapi-with-mic, hostbased, publickey, keyboard-interactive, password`	Client	v2
`Port`	`22`	Both
`PrintMotd`	`no`	Server
`Protocol`	`2`	Both
`ProxyCommand`	No default.	Client
`PubkeyAuthentication`	`yes`	Both	v2
`RemoteForward`	No default.	Client
`RhostsAuthentication`	`no`	Both	v1
`RhostsRSAAuthentication`	`no`	Both	v1
`RSAAuthentication`	`no`	Both	v1

Table 20–4 Keywords in Solaris Secure Shell Configuration Files (S to X)


Keyword	Default Value	Location	Protocol
`ServerKeyBits`	`768`	Server
`StrictHostKeyChecking`	`ask`	Client
`StrictModes`	`yes`	Server
`Subsystem`	`sftp /usr/lib/ssh/sftp-server`	Server
`SyslogFacility`	`auth`	Server
`UseLogin`	`no` Deprecated and ignored.	Server
`UseOpenSSLEngine`	`yes`	Both	v2
`User`	No default.	Client
`UserKnownHostsFile`	`~/.ssh/known_hosts`	Client
`VerifyReverseMapping`	`no`	Server
`X11Forwarding`	`yes`	Server
`X11DisplayOffset`	`10`	Server
`X11UseLocalHost`	`yes`	Server
`XAuthLocation`	`/usr/openwin/bin/xauth`	Both

Host-Specific Parameters in Solaris Secure Shell

If it is useful to have different Solaris Secure Shell characteristics for different local hosts, the administrator can define separate sets of parameters in the /etc/ssh/ssh_config file to be applied according to host or regular expression. This task is done by grouping entries in the file by Host keyword. If the Host keyword is not used, the entries in the client configuration file apply to whichever local host a user is working on.

Solaris Secure Shell and Login Environment Variables

When the following Solaris Secure Shell keywords are not set in the sshd_config file, they get their value from equivalent entries in the /etc/default/login file:

Entry in `/etc/default/login`	Keyword and Value in `sshd_config`
`CONSOLE=*`	`PermitRootLogin=without-password`
`#CONSOLE=*`	`PermitRootLogin=yes`
`PASSREQ=YES`	`PermitEmptyPasswords=no`
`PASSREQ=NO`	`PermitEmptyPasswords=yes`
`#PASSREQ`	`PermitEmptyPasswords=no`
`TIMEOUT=secs`	`LoginGraceTime=secs`
`#TIMEOUT`	`LoginGraceTime=300`
`RETRIES` and `SYSLOG_FAILED_LOGINS`	Apply only to `password` and `keyboard-interactive` authentication methods.

When the following variables are set by the initialization scripts from the user's login shell, the sshd daemon uses those values. When the variables are not set, the daemon uses the default value.

TIMEZONE: Controls the setting of the TZ environment variable. When not set, the sshd daemon uses value of TZ when the daemon was started.
ALTSHELL: Controls the setting of the SHELL environment variable. The default is ALTSHELL=YES, where the sshd daemon uses the value of the user's shell. When ALTSHELL=NO, the SHELL value is not set.
PATH: Controls the setting of the PATH environment variable. When the value is not set, the default path is /usr/bin.
SUPATH: Controls the setting of the PATH environment variable for root. When the value is not set, the default path is /usr/sbin:/usr/bin.

For more information, see the login(1) and sshd(1M) man pages.

Maintaining Known Hosts in Solaris Secure Shell

Each host that needs to communicate securely with another host must have the server's public key stored in the local host's /etc/ssh/ssh_known_hosts file. Although a script could be used to update the /etc/ssh/ssh_known_hosts files, such a practice is heavily discouraged because a script opens a major security vulnerability.

The /etc/ssh/ssh_known_hosts file should only be distributed by a secure mechanism as follows:

Over a secure connection, such as Solaris Secure Shell, IPsec, or Kerberized ftp from a known and trusted machine
At system install time

To avoid the possibility of an intruder gaining access by inserting bogus public keys into a known_hosts file, you should use a JumpStart^TM server as the known and trusted source of the ssh_known_hosts file. The ssh_known_hosts file can be distributed during installation. Later, scripts that use the scp command can be used to pull in the latest version. This approach is secure because each host already has the public key from the JumpStart server.

Solaris Secure Shell Packages and Initialization

Solaris Secure Shell depends on core Solaris packages and the following packages:

SUNWgss – Contains Generic Security Service (GSS) software
SUNWtcpd – Contains TCP wrappers
SUNWopenssl-libraries – Contains OpenSSL libraries
SUNWzlib – Contains the zip compression library

The following packages install Solaris Secure Shell:

SUNWsshr – Contains client files and utilities for the root (/) directory
SUNWsshdr – Contains server files and utilities for the root (/) directory
SUNWsshcu – Contains common source files for the /usr directory
SUNWsshdu – Contains server files for the /usr directory
SUNWsshu – Contains client files and utilities for the /usr directory

Upon reboot after installation, the sshd daemon is running. The daemon creates host keys on the system. A Solaris system that runs the sshd daemon is a Solaris Secure Shell server.

Solaris Secure Shell Files

The following table shows the important Solaris Secure Shell files and the suggested file permissions.

Table 20–5 Solaris Secure Shell Files


File Name	Description	Suggested Permissions and Owner
`/etc/ssh/sshd_config`	Contains configuration data for `sshd`, the Solaris Secure Shell daemon.	`-rw-r--r-- root`
`/etc/ssh/ssh_host_key`	Contains the host private key (v1).	`-rw------- root`
`/etc/ssh/ssh_host_dsa_key` or `/etc/ssh/ssh_host_rsa_key`	Contains the host private key (v2).	`-rw------- root`
`host-private-key.pub`	Contains the host public key, for example, `/etc/ssh/ssh_host_rsa_key.pub`. Is used to copy the host key to the local `known_hosts` file.	`-rw-r--r-- root`
`/var/run/sshd.pid`	Contains the process ID of the Solaris Secure Shell daemon, `sshd`. If multiple daemons are running, the file contains the last daemon that was started.	`-rw-r--r-- root`
`~/.ssh/authorized_keys`	Holds the public keys of the user who is allowed to log in to the user account.	`-rw-r--r--` `username`
`/etc/ssh/ssh_known_hosts`	Contains the host public keys for all hosts with which the client can communicate securely. The file is populated by the administrator.	`-rw-r--r-- root`
`~/.ssh/known_hosts`	Contains the host public keys for all hosts with which the client can communicate securely. The file is maintained automatically. Whenever the user connects with an unknown host, the remote host key is added to the file.	`-rw-r--r--` `username`
`/etc/default/login`	Provides defaults for the `sshd` daemon when corresponding `sshd_config` parameters are not set.	`-r--r--r-- root`
`/etc/nologin`	If this file exists, the `sshd` daemon only permits `root` to log in. The contents of this file are displayed to users who are attempting to log in.	`-rw-r--r-- root`
`~/.rhosts`	Contains the host-user name pairs that specify the hosts to which the user can log in without a password. This file is also used by the `rlogind` and `rshd` daemons.	`-rw-r--r--` `username`
`~/.shosts`	Contains the host-user name pairs that specify the hosts to which the user can log in without a password. This file is not used by other utilities. For more information, see the sshd(1M)man page in the `FILES` section.	`-rw-r--r--` `username`
`/etc/hosts.equiv`	Contains the hosts that are used in `.rhosts` authentication. This file is also used by the `rlogind` and `rshd` daemons.	`-rw-r--r-- root`
`/etc/ssh/shosts.equiv`	Contains the hosts that are used in host-based authentication. This file is not used by other utilities.	`-rw-r--r-- root`
`~/.ssh/environment`	Contains initial assignments at login. By default, this file is not read. The `PermitUserEnvironment` keyword in the `sshd_config` file must be set to `yes` for this file to be read.	`-rw-r--r--` `username`
`~/.ssh/rc`	Contains initialization routines that are run before the user shell starts. For a sample initialization routine, see the sshd man page.	`-rw-r--r--` `username`
`/etc/ssh/sshrc`	Contains host-specific initialization routines that are specified by an administrator.	`-rw-r--r-- root`
`/etc/ssh/ssh_config`	Configures system settings on the client system.	`-rw-r--r-- root`
`~/.ssh/config`	Configures user settings. Overrides system settings.	`-rw-r--r--` `username`

The following table lists the Solaris Secure Shell files that can be overridden by keywords or command options.

Table 20–6 Overrides for the Location of Solaris Secure Shell Files


File Name	Keyword Override	Command-Line Override
`/etc/ssh/ssh_config`		`ssh -F` `config-file` `scp -F` `config-file`
`~/.ssh/config`		`ssh -F` `config-file`
`/etc/ssh/host_rsa_key` `/etc/ssh/host_dsa_key`	`HostKey`
`~/.ssh/identity` `~/.ssh/id_dsa`, `~/.ssh/id_rsa`	`IdentityFile`	`ssh -i` `id-file` `scp -i` `id-file`
`~/.ssh/authorized_keys`	`AuthorizedKeysFile`
`/etc/ssh/ssh_known_hosts`	`GlobalKnownHostsFile`
`~/.ssh/known_hosts`	`UserKnownHostsFile` `IgnoreUserKnownHosts`

Solaris Secure Shell Commands

The following table summarizes the major Solaris Secure Shell commands.

Table 20–7 Commands in Solaris Secure Shell


Command	Description	Man Page
`ssh`	Logs a user in to a remote machine and securely executes commands on a remote machine. This command is the Solaris Secure Shell replacement for the `rlogin` and `rsh` commands. The `ssh` command enables secure encrypted communications between two untrusted hosts over an insecure network. X11 connections and arbitrary TCP/IP ports can also be forwarded over the secure channel.	ssh(1)
`sshd`	Is the daemon for Solaris Secure Shell. The daemon listens for connections from clients and enables secure encrypted communications between two untrusted hosts over an insecure network.	sshd(1M)
`ssh-add`	Adds RSA or DSA identities to the authentication agent, `ssh-agent`. Identities are also called keys.	ssh-add(1)
`ssh-agent`	Holds private keys that are used for public key authentication. The `ssh-agent` program is started at the beginning of an X-session or a login session. All other windows and other programs are started as clients of the `ssh-agent` program. Through the use of environment variables, the agent can be located and used for authentication when users use the `ssh` command to log in to other systems.	ssh-agent(1)
`ssh-keygen`	Generates and manages authentication keys for Solaris Secure Shell.	ssh-keygen(1)
`ssh-keyscan`	Gathers the public keys of a number of Solaris Secure Shell hosts. Aids in building and verifying `ssh_known_hosts` files.	ssh-keyscan(1)
`ssh-keysign`	Is used by the `ssh` command to access the host keys on the local host. Generates the digital signature that is required during host-based authentication with Solaris Secure Shell v2. The command is invoked by the `ssh` command, not by the user.	ssh-keysign(1M)
`scp`	Securely copies files between hosts on a network over an encrypted `ssh` transport. Unlike the `rcp` command, the `scp` command prompts for passwords or passphrases, if password information is needed for authentication.	scp(1)
`sftp`	Is an interactive file transfer program that is similar to the `ftp` command. Unlike the `ftp` command, the `sftp` command performs all operations over an encrypted `ssh` transport. The command connects, logs in to the specified host name, and then enters interactive command mode.	sftp(1)

The following table lists the command options that override Solaris Secure Shell keywords. The keywords are specified in the ssh_config and sshd_config files.

Table 20–8 Command-Line Equivalents for Solaris Secure Shell Keywords


Keyword	`ssh` Command-Line Override	`scp` Command-Line Override
`BatchMode`		`scp -B`
`BindAddress`	`ssh -b` `bind-addr`	`scp -a` `bind-addr`
`Cipher`	`ssh -c` `cipher`	`scp -c` `cipher`
`Ciphers`	`ssh -c` `cipher-spec`	`scp -c` `cipher-spec`
`Compression`	`ssh -C`	`scp -C`
`DynamicForward`	`ssh -D` `SOCKS4-port`
`EscapeChar`	`ssh -e` `escape-char`
`ForwardAgent`	`ssh -A` to enable `ssh -a` to disable
`ForwardX11`	`ssh -X` to enable `ssh -x` to disable
`GatewayPorts`	`ssh -g`
`IPv4`	`ssh -4`	`scp -4`
`IPv6`	`ssh -6`	`scp -6`
`LocalForward`	`ssh -L` `localport:remotehost:remoteport`
`MACS`	`ssh -m` `mac-spec`
`Port`	`ssh -p` `port`	`scp -P` `port`
`Protocol`	`ssh -1` for v1 only `ssh -2` for v2 only
`RemoteForward`	`ssh -R` `remoteport:localhost:localport`