Part V Authentication Services and Secure Communication

This section discusses authentication services that can be configured on a non-networked system, or between two systems. To configure a network of authenticated users and systems, see Part VI, Kerberos Service.

Chapter 16 Using Authentication Services (Tasks)

This chapter provides information about how to use Secure RPC to authenticate a host and a user across an NFS mount. The following is a list of the topics in this chapter.

• Overview of Secure RPC

• Administering Secure RPC (Task Map)

Overview of Secure RPC

Secure RPC (Remote Procedure Call) protects remote procedures with an authentication mechanism. The Diffie-Hellman authentication mechanism authenticates both the host and the user who is making a request for a service. The authentication mechanism uses Data Encryption Standard (DES) encryption. Applications that use Secure RPC include NFS and the name services, NIS and NIS+.

NFS Services and Secure RPC

NFS enables several hosts to share files over the network. Under the NFS service, a server holds the data and resources for several clients. The clients have access to the file systems that the server shares with the clients. Users who are logged in to the client systems can access the file systems by mounting the file systems from the server. To the user on the client system, it appears as if the files are local to the client. One of the most common uses of NFS allows systems to be installed in offices, while storing all user files in a central location. Some features of the NFS service, such as the -nosuid option to the mount command, can be used to prohibit the opening of devices and file systems by unauthorized users.

The NFS service uses Secure RPC to authenticate users who make requests over the network. This process is known as Secure NFS. The Diffie-Hellman authentication mechanism, AUTH_DH, uses DES encryption to ensure authorized access. The AUTH_DH mechanism has also been called AUTH_DES. For more information, see the following:

• To set up and administer Secure NFS, see Administering the Secure NFS System in System Administration Guide: Network Services.

• To set up the NIS+ tables and enter names in the cred table, see System Administration Guide: Naming and Directory Services (NIS+).

• For an outline of the transactions that are involved in RPC authentication, see Implementation of Diffie-Hellman Authentication.

DES Encryption With Secure NFS

The Data Encryption Standard (DES) encryption functions use a 56-bit key to encrypt data. If two credential users or principals know the same DES key, they can communicate in private by using the key to encipher and decipher text. DES is a relatively fast encryption mechanism. A DES chip makes the encryption even faster. However, if the chip is not present, a software implementation is substituted.

The risk of using just the DES key is that an intruder can collect enough cipher-text messages that were encrypted with the same key to be able to discover the key and decipher the messages. For this reason, security systems such as Secure NFS need to change the keys frequently.

Kerberos Authentication

Kerberos is an authentication system that was developed at MIT. Some encryption in Kerberos is based on DES. Kerberos V4 support is no longer supplied as part of Secure RPC. However, a client-side and server-side implementation of Kerberos V5, which uses RPCSEC_GSS, is included with this release. For more information, see Chapter 21, Introduction to the Kerberos Service.

Diffie-Hellman Authentication and Secure RPC

The Diffie-Hellman (DH) method of authenticating a user is nontrivial for an intruder to crack. The client and the server have their own private key, which they use with the public key to devise a common key. The private key is also known as the secret key. The client and the server use the common key to communicate with each other. The common key is encrypted with an agreed-upon encryption function, such as DES.

Authentication is based on the ability of the sending system to use the common key to encrypt the current time. Then, the receiving system can decrypt and check against its current time. The time on the client and the server must be synchronized. For more information, see Managing Network Time Protocol (Tasks) in System Administration Guide: Network Services.

The public keys and private keys are stored in an NIS or NIS+ database. NIS stores the keys in the publickey map. NIS+ stores the keys in the cred table. These files contain the public key and the private key for all potential users.

The system administrator is responsible for setting up NIS maps or NIS+ tables, and for generating a public key and a private key for each user. The private key is stored in encrypted form with the user's password. This process makes the private key known only to the user.

Implementation of Diffie-Hellman Authentication

This section describes the series of transactions in a client-server session that use Diffie-Hellman authentication (AUTH_DH).

Generating the Public Keys and Secret Keys for Secure RPC

Sometime prior to a transaction, the administrator runs either the newkey or the nisaddcred command to generate a public key and a secret key. Each user has a unique public key and secret key. The public key is stored in a public database. The secret key is stored in encrypted form in the same database. The chkey command changes the key pair.

Running the keylogin Command for Secure RPC

Normally, the login password is identical to the Secure RPC password. In this case, the keylogin command is not required. However, if the passwords are different, the users have to log in and then run the keylogin command.

The keylogin command prompts the user for a Secure RPC password. The command then uses the password to decrypt the secret key. The keylogin command then passes the decrypted secret key to the keyserver program. The keyserver is an RPC service with a local instance on every computer. The keyserver saves the decrypted secret key and waits for the user to initiate a Secure RPC transaction with a server.

If both the login password and the RPC password are the same, the login process passes the secret key to the keyserver. If the passwords are required to be different, then the user must always run the keylogin command. When the keylogin command is included in the user's environment configuration file, such as the ~/.login, ~/.cshrc, or ~/.profile file, the keylogin command runs automatically whenever the user logs in.

Generating the Conversation Key for Secure RPC

When the user initiates a transaction with a server, the following occurs:

1. The keyserver randomly generates a conversation key.

2. The kernel uses the conversation key, plus other material, to encrypt the client's timestamp.

3. The keyserver looks up the server's public key in the public key database. For more information, see the publickey(4) man page.

4. The keyserver uses the client's secret key and the server's public key to create a common key.

5. The keyserver encrypts the conversation key with the common key.

Initially Contacting the Server in Secure RPC

The transmission, which includes the encrypted timestamp and the encrypted conversation key, is then sent to the server. The transmission includes a credential and a verifier. The credential contains three components:

• The client's network name

• The conversation key, which is encrypted with the common key

• A “window,” which is encrypted with the conversation key

The window is the difference in time that the client says should be allowed between the server's clock and the client's timestamp. If the difference between the server's clock and the timestamp is greater than the window, the server rejects the client's request. Under normal circumstances, this rejection does not happen, because the client first synchronizes with the server before starting the RPC session.

The client's verifier contains the following:

• The encrypted timestamp

• An encrypted verifier of the specified window, which is decremented by 1

The window verifier is needed in case somebody wants to impersonate a user. The impersonator can write a program that, instead of filling in the encrypted fields of the credential and verifier, just inserts random bits. The server decrypts the conversation key into some random key. The server then uses the key to try to decrypt the window and the timestamp. The result is random numbers. After a few thousand trials, however, the random window/timestamp pair is likely to pass the authentication system. The window verifier lessens the chance that a fake credential could be authenticated.

Decrypting the Conversation Key in Secure RPC

When the server receives the transmission from the client, the following occurs:

1. The keyserver that is local to the server looks up the client's public key in the public key database.

2. The keyserver uses the client's public key and the server's secret key to deduce the common key. The common key is the same common key that is computed by the client. Only the server and the client can calculate the common key because the calculation requires knowing one of the secret keys.

3. The kernel uses the common key to decrypt the conversation key.

4. The kernel calls the keyserver to decrypt the client's timestamp with the decrypted conversation key.

Storing Information on the Server in Secure RPC

After the server decrypts the client's timestamp, the server stores four items of information in a credential table:

• The client's computer name

• The conversation key

• The window

• The client's timestamp

The server stores the first three items for future use. The server stores the client's timestamp to protect against replays. The server accepts only timestamps that are chronologically greater than the last timestamp seen. As a result, any replayed transactions are guaranteed to be rejected.

Implicit in these transactions is the name of the caller, who must be authenticated in some manner. The keyserver cannot use DES authentication to authenticate the caller because the use of DES by the keyserver would create a deadlock. To avoid a deadlock, the keyserver stores the secret keys by user ID (UID) and grants requests only to local root processes.

Returning the Verifier to the Client in Secure RPC

The server returns a verifier to the client, which includes the following:

• The index ID, which the server records in its credential cache

• The client's timestamp minus 1, which is encrypted by the conversation key

The reason for subtracting 1 from the client's timestamp is to ensure that the timestamp is out of date. An out-of-date timestamp cannot be reused as a client verifier.

Authenticating the Server in Secure RPC

The client receives the verifier and authenticates the server. The client knows that only the server could have sent the verifier because only the server knows what timestamp the client sent.

Handling Transactions in Secure RPC

With every transaction after the first transaction, the client returns the index ID to the server in its next transaction. The client also sends another encrypted timestamp. The server sends back the client's timestamp minus 1, which is encrypted by the conversation key.

Administering Secure RPC (Task Map)

The following task map points to procedures that configure Secure RPC for NIS, NIS+, and NFS.

Administering Authentication With Secure RPC

By requiring authentication for use of mounted NFS file systems, you increase the security of your network.

How to Restart the Secure RPC Keyserver

1. Assume the Primary Administrator role, or become superuser.

   The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

2. Verify that the keyserv daemon is running.

   # svcs \*keyserv\* STATE STIME FMRI disabled Dec_14 svc:/network/rpc/keyserv

3. Enable the keyserver service if the service is not online.

   # svcadm enable network/rpc/keyserv

How to Set Up a Diffie-Hellman Key for an NIS+ Host

This procedure should be done on every host in the NIS+ domain. After root has run the keylogin command, the server has GSS-API acceptor credentials for mech_dh and the client has GSS-API initiator credentials.

For a detailed description of NIS+ security, see System Administration Guide: Naming and Directory Services (NIS+).

1. Assume the Primary Administrator role, or become superuser.

   The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

2. Enable the publickey table in the name service.

   Add the following line to the /etc/nsswitch.conf file:

   publickey: nisplus

3. Initialize the NIS+ client.

   # nisinit -cH hostname

   where hostname is the name of a trusted NIS+ server that contains an entry in its tables for the client system.

4. Add the client to the cred table.

   Type the following commands:

   # nisaddcred local # nisaddcred des

5. Verify the setup by using the keylogin command.

   If you are prompted for a password, the procedure has succeeded.

   # keylogin Password:

Example 16–1 Setting Up a New Key for root on an NIS+ Client

The following example uses the host pluto to set up earth as an NIS+ client. You can ignore the warnings. The keylogin command is accepted, verifying that earth is correctly set up as a secure NIS+ client.

# nisinit -cH pluto
NIS Server/Client setup utility.
This system is in the example.com. directory.
Setting up NIS+ client ...
All done.
# nisaddcred local
# nisaddcred des 
DES principal name : unix.earth@example.com
Adding new key for unix.earth@example.com (earth.example.com.)
Network password:<Type password>
Warning, password differs from login password.
Retype password: <Retype password>
# keylogin
Password:        <Type password>
#

How to Set Up a Diffie-Hellman Key for an NIS+ User

This procedure should be done on every user in the NIS+ domain.

1. Assume the Primary Administrator role, or become superuser.

   The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

2. Add the user to the cred table on the root master server.

   Type the following command:

   # nisaddcred -p unix.UID@domain-name -P username.domain-name. des

   Note that, in this case, the username.domain-name must end with a dot (.).

3. Verify the setup by logging in as the client and typing the keylogin command.

Example 16–2 Setting Up a New Key for an NIS+ User

In the following example, a key for Diffie-Hellman authentication is given to the user jdoe.

# nisaddcred -p unix.1234@example.com -P jdoe.example.com. des
DES principal name : unix.1234@example.com
Adding new key for unix.1234@example.com (jdoe.example.com.)
Password:       <Type password>
Retype password:<Retype password>
# rlogin rootmaster -l jdoe
% keylogin
Password:       <Type password>
%

How to Set Up a Diffie-Hellman Key for an NIS Host

This procedure should be done on every host in the NIS domain.

1. Assume the Primary Administrator role, or become superuser.

   The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

2. Enable the publickey map in the name service.

   Add the following line to the /etc/nsswitch.conf file:

   publickey: nis

3. Create a new key pair by using the newkey command.

   # newkey -h hostname

   where hostname is the name of the client.

Example 16–3 Setting Up a New Key for root on an NIS Client

In the following example, earth is set up as a secure NIS client.

# newkey -h earth
Adding new key for unix.earth@example.com
New Password:   <Type password>
Retype password:<Retype password>
Please wait for the database to get updated...
Your new key has been successfully stored away.
#

How to Set Up a Diffie-Hellman Key for an NIS User

This procedure should be done for every user in the NIS domain.

Before You Begin

Only system administrators, when logged in to the NIS master server, can generate a new key for a user.

1. Assume the Primary Administrator role, or become superuser.

   The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

2. Create a new key for a user.

   # newkey -u username

   where username is the name of the user. The system prompts for a password. You can type a generic password. The private key is stored in an encrypted form by using the generic password.

3. Tell the user to log in and type the chkey -p command.

   This command allows users to re-encrypt their private keys with a password known only to the user.

   ---

   Note –

   The chkey command can be used to create a new key pair for a user.

   ---

Example 16–4 Setting Up and Encrypting a New User Key in NIS

In this example, superuser sets up the key.

# newkey -u jdoe
Adding new key for unix.12345@example.com
New Password:   <Type password>
Retype password:<Retype password>
Please wait for the database to get updated...
Your new key has been successfully stored away.
#

Then the user jdoe re-encrypts the key with a private password.

% chkey -p
Updating nis publickey database.
Reencrypting key for unix.12345@example.com
Please enter the Secure-RPC password for jdoe:<Type password>
Please enter the login password for jdoe:     <Type password>
Sending key change request to centralexample...

How to Share NFS Files With Diffie-Hellman Authentication

This procedure protects shared file systems on an NFS server by requiring authentication for access.

Before You Begin

Diffie-Hellman public key authentication must be enabled on the network. To enable authentication on the network, do one of the following:

• How to Set Up a Diffie-Hellman Key for an NIS+ Host

• How to Set Up a Diffie-Hellman Key for an NIS Host

1. Become superuser or assume a role that includes the System Management profile.

   The System Administrator role includes the System Management profile. To create the role and assign the role to a user, see Configuring RBAC (Task Map).

2. On the NFS server, share a file system with Diffie-Hellman authentication.

   # share -F nfs -o sec=dh /filesystem

   where filesystem is the file system that is being shared.

   The -o sec=dh option means that AUTH_DH authentication is now required to access the file system.

3. On an NFS client, mount a file system with Diffie-Hellman authentication.

   # mount -F nfs -o sec=dh server:filesystem mount-point

   server

   Is the name of the system that is sharing filesystem

   filesystem

   Is the name of the file system that is being shared, such as opt

   mount-point

   Is the name of the mount point, such as /opt

   The -o sec=dh option mounts the file system with AUTH_DH authentication.

Chapter 17 Using PAM

This chapter covers the Pluggable Authentication Module (PAM) framework. PAM provides a method to “plug in” authentication services into the Solaris Operating System (Solaris OS). PAM provides support for multiple authentication services when accessing a system.

• PAM (Overview)

• PAM (Tasks)

• PAM Configuration (Reference)

PAM (Overview)

The Pluggable Authentication Module (PAM) framework lets you “plug in” new authentication services without changing system entry services, such as login, ftp, and telnet. You can also use PAM to integrate UNIX login with other security mechanisms such as Kerberos. Mechanisms for account, credential, session, and password management can also be “plugged in” by using this framework.

Benefits of Using PAM

The PAM framework enables you to configure the use of system entry services (such as, ftp, login, telnet, or rsh) for user authentication. Some benefits that PAM provides are as follows:

• Flexible configuration policy

  • Per-application authentication policy

  • The ability to choose a default authentication mechanism

  • The ability to require multiple authorizations on high-security systems

• Ease of use for the end user

  • No retyping of passwords if the passwords are the same for different authentication services

  • The ability to prompt the user for passwords for multiple authentication services without requiring the user to type multiple commands

• The ability to pass optional options to the user authentication services

• The ability to implement a site-specific security policy without having to change the system entry services

Introduction to the PAM Framework

The PAM framework consists of four parts:

• PAM consumers

• PAM library

• The pam.conf(4) configuration file

• PAM service modules, also referred to as providers

The framework provides a uniform way for authentication-related activities to take place. This approach enables application developers to use PAM services without having to know the semantics of the policy. Algorithms are centrally supplied. The algorithms can be modified independently of the individual applications. With PAM, administrators can tailor the authentication process to the needs of a particular system without having to change any applications. Adjustments are made through pam.conf, the PAM configuration file.

The following figure illustrates the PAM architecture. Applications communicate with the PAM library through the PAM application programming interface (API). PAM modules communicate with the PAM library through the PAM service provider interface (SPI). Thus, the PAM library enables applications and modules to communicate with each other.

Figure 17–1 PAM Architecture

Changes to PAM for the Solaris 10 Release

The Solaris 10 release includes the following changes to the Pluggable Authentication Module (PAM) framework:

• The pam_authtok_check module now allows for strict password checking using new tunable parameters in the /etc/default/passwd file. The new parameters define:

  • A list of comma separated dictionary files used for checking common dictionary words in a password

  • The minimum differences required between a new password and an old password

  • The minimum number of alphabetic or nonalphabetic characters that must be used in a new password

  • The minimum number of uppercase or lowercase letters that must be used in a new password

  • The number of allowable consecutive repeating characters

• The pam_unix_auth module implements account locking for local users. Account locking is enabled by the LOCK_AFTER_RETRIES parameter in /etc/security/policy.conf and the lock_after-retries key in /etc/user_attr. See the policy.conf(4) and the user_attr(4) man pages for more information.

• A new binding control flag has been defined. This control flag is documented in the pam.conf(4) man page and in How PAM Stacking Works.

• The pam_unix module has been removed and replaced by a set of service modules of equivalent or greater functionality. Many of these modules were introduced in the Solaris 9 release. Here is a list of the replacement modules:

  • pam_authtok_check

  • pam_authtok_get

  • pam_authtok_store

  • pam_dhkeys

  • pam_passwd_auth

  • pam_unix_account

  • pam_unix_auth

  • pam_unix_cred

  • pam_unix_session

• The functionality of the pam_unix_auth module has been split into two modules. The pam_unix_auth module now verifies that the password is correct for the user. The new pam_unix_cred module provides functions that establish user credential information.

• Additions to the pam_krb5 module have been made to manage the Kerberos credentials cache using the PAM framework.

• A new pam_deny module has been added. The module can be used to deny access to services. By default, the pam_deny module is not used. For more information, see the pam_deny(5) man page.

Changes to PAM for the Solaris Express 1/06 Release

The PAM framework for the Solaris Express 1/06 release includes a new pam_allow module. The module can be used to grant access to all users, without enforcing any security. The module should be used with caution. For more information, see the pam_allow(5) man page.

PAM (Tasks)

This section discusses some tasks that might be required to make the PAM framework use a particular security policy. You should be aware of some security issues that are associated with the PAM configuration file. For information about the security issues, see Planning for Your PAM Implementation.

PAM (Task Map)

Planning for Your PAM Implementation

As delivered, the pam.conf configuration file implements the standard Solaris security policy. This policy should work in many situations. If you need to implement a different security policy, here are the issues that you should focus on:

• Determine what your needs are, especially which PAM service modules you should select.

• Identify the services that need special configuration options. Use other if appropriate.

• Decide the order in which the modules should be run.

• Select the control flag for each module. See How PAM Stacking Works for more information about all of the control flags.

• Choose any options that are necessary for each module. The man page for each module should list any special options.

Here are some suggestions to consider before you change the PAM configuration file:

• Use other entries for each module type so that every application does not have to be included in /etc/pam.conf.

• Make sure to consider the security implications of the binding, sufficient, and optional control flags.

• Review the man pages that are associated with the modules. These man pages can help you understand how each module functions, what options are available, and the interactions between stacked modules.

  ---

  Caution –

  If the PAM configuration file is misconfigured or the file becomes corrupted, no user might be able to log in. Because the sulogin command does not use PAM, the root password would then be required to boot the machine into single-user mode and fix the problem.

  ---

  After you change the /etc/pam.conf file, review the file as much as possible while you still have system access to correct problems. Test all the commands that might have been affected by your changes. An example is adding a new module to the telnet service. In this example, you would use the telnet command and verify that your changes make the service behave as expected.

How to Add a PAM Module

This procedure shows how to add a new PAM module. New modules can be created to cover site-specific security policies or to support third party applications.

1. Become superuser or assume an equivalent role.

   Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map).

2. Determine which control flags and which other options should be used.

   Refer to How PAM Stacking Works for information on the control flags.

3. Ensure that the ownership and permissions are set so that the module file is owned by root and the permissions are 555.

4. Edit the PAM configuration file, /etc/pam.conf, and add this module to the appropriate services.

5. Verify that the module has been added properly.

   You must test before the system is rebooted in case the configuration file is misconfigured. Login using a direct service, such as ssh, and run the su command, before you reboot the system. The service might be a daemon that is spawned only once when the system is booted. Then, you must reboot the system before you can verify that the module has been added.

How to Prevent Rhost-Style Access From Remote Systems With PAM

1. Become superuser or assume an equivalent role.

   Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map).

2. Remove all of the lines that include rhosts_auth.so.1 from the PAM configuration file.

   This step prevents the reading of the ~/.rhosts files during an rlogin session. Therefore, this step prevents unauthenticated access to the local system from remote systems. All rlogin access requires a password, regardless of the presence or contents of any ~/.rhosts or /etc/hosts.equiv files.

3. Disable the rsh service.

   To prevent other unauthenticated access to the ~/.rhosts files, remember to disable the rsh service.

   # svcadm disable network/shell

How to Log PAM Error Reports

1. Become superuser or assume an equivalent role.

   Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map).

2. Configure the /etc/syslog.conf file for the level of logging that you need.

   See the syslog.conf(4) for more information about the logging levels.

3. Refresh the configuration information for the syslog daemon.

   # svcadm refresh system/system-log

PAM Configuration (Reference)

The PAM configuration file, pam.conf(4), is used to configure PAM service modules for system services, such as login, rlogin, su, and cron. The system administrator manages this file. An incorrect order of entries in pam.conf can cause unforeseen side effects. For example, a badly configured pam.conf can lock out users so that single-user mode becomes necessary for repair. For a description of setting the order, see How PAM Stacking Works.

PAM Configuration File Syntax

The entries in the configuration file are in the format:

service-name module-type control-flag module-path module-options

service-name

Name of the service, for example, ftp, login, or passwd. An application can use different service names for the services that the application provides. For example, the Solaris secure shell daemon uses these service names: sshd-none, sshd-password, sshd-kbdint, sshd-pubkey, and sshd-hostbased. The service-name other is a predefined name that is used as a wildcard service-name. If a particular service-name is not found in the configuration file, the configuration for other is used.

module-type

The type of service, that is, auth, account, session, or password.

control-flag

Indicates the role of the module in determining the integrated success or failure value for the service. Valid control flags are binding, include, optional, required, requisite, and sufficient. See How PAM Stacking Works for information on the use of these flags.

module-path

The path to the library object that implements the service. If the pathname is not absolute, the pathname is assumed to be relative to /usr/lib/security/$ISA/. Use the architecture-dependent macro $ISA to cause libpam to look in the directory for the particular architecture of the application.

module-options

Options that are passed to the service modules. A module's man page describes the options that are accepted by that module. Typical module options include nowarn and debug.

How PAM Stacking Works

When an application calls on the following functions, libpam reads the configuration file /etc/pam.conf to determine which modules participate in the operation for this service:

• pam_authenticate(3PAM)

• pam_acct_mgmt(3PAM)

• pam_setcred(3PAM)

• pam_open_session(3PAM)

• pam_close_session(3PAM)

• pam_chauthtok(3PAM)

If /etc/pam.conf contains only one module for an operation for this service such as authentication or account management, the result of that module determines the outcome of the operation. For example, the default authentication operation for the passwd application contains one module, pam_passwd_auth.so.1:

passwd  auth required           pam_passwd_auth.so.1

If, on the other hand, there are multiple modules defined for the service's operation, those modules are said to be stacked and that a PAM stack exists for that service. For example, consider the case where pam.conf contains the following entries:

login   auth requisite          pam_authtok_get.so.1
login   auth required           pam_dhkeys.so.1
login   auth required           pam_unix_cred.so.1
login   auth required           pam_unix_auth.so.1
login   auth required           pam_dial_auth.so.1

These entries represent a sample auth stack for the login service. To determine the outcome of this stack, the result codes of the individual modules require an integration process. In the integration process, the modules are executed in order as specified in /etc/pam.conf. Each success or failure code is integrated in the overall result depending on the module's control flag. The control flag can cause early termination of the stack. For example, a requisite module might fail, or a sufficient or binding module might succeed. After the stack has been processed, the individual results are combined into a single, overall result that is delivered to the application.

The control flag indicates the role that a PAM module plays in determining access to the service. The control flags and their effects are:

• Binding – Success in meeting a binding module's requirements returns success immediately to the application if no previous required modules have failed. If these conditions are met, then no further execution of modules occurs. Failure causes a required failure to be recorded and the processing of modules to be continued.

• Include – Adds lines from a separate PAM configuration file to be used at this point in the PAM stack. This flag does not control success or failure behaviors. When a new file is read, the PAM include stack is incremented. When the stack check in the new file finishes, the include stack value is decremented. When the end of a file is reached and the PAM include stack is 0, then the stack processing ends. The maximum number for the PAM include stack is 32.

• Optional – Success in meeting an optional module's requirements is not necessary for using the service. Failure causes an optional failure to be recorded.

• Required – Success in meeting a required module's requirements is necessary for using the service. Failure results in an error return after the remaining modules for this service have been executed. Final success for the service is returned only if no binding or required modules have reported failures.

• Requisite – Success in meeting a requisite module's requirements is necessary for using the service. Failure results in an immediate error return with no further execution of modules. All requisite modules for a service must return success for the function to be able to return success to the application.

• Sufficient – If no previous required failures have occurred, success in a sufficient module returns success to the application immediately with no further execution of modules. Failure causes an optional failure to be recorded.

The following two diagrams shows how access is determined in the integration process. The first diagram indicates how success or failure is recorded for each type of control flag. The second diagram shows how the integrated value is determined.

Figure 17–2 PAM Stacking: Effect of Control Flags

Figure 17–3 PAM Stacking: How Integrated Value Is Determined

PAM Stacking Example

Consider the following example of an rlogin service that requests authentication.

Example 17–1 Partial Contents of a Typical PAM Configuration File

The pam.conf file in this example has the following contents for rlogin services:

     # Authentication management
     ...     
     # rlogin service 
     rlogin  auth sufficient         pam_rhosts_auth.so.1
     rlogin  auth requisite          pam_authtok_get.so.1
     rlogin  auth required           pam_dhkeys.so.1
     rlogin  auth required           pam_unix_auth.so.1
     ...

When the rlogin service requests authentication, libpam first executes the pam_rhosts_auth(5) module. The control flag is set to sufficient for the pam_rhosts_auth module. If the pam_rhosts_auth module is able to authenticate the user, then processing stops and success is returned to the application.

If the pam_rhosts_auth module fails to authenticate the user, then the next PAM module, pam_authtok_get(5) is executed. The control flag for this module is set to requisite. If pam_authtok_get fails, then the authentication process ends and the failure is returned to rlogin.

If pam_authtok_get succeeds, then the next two modules, pam_dhkeys(5) and pam_unix_auth(5), are executed. Both modules have the associated control flags that are set to required so that the process continues regardless of whether an individual failure is returned. After pam_unix_auth is executed, no modules for rlogin authentication remain. At this point, if either pam_dhkeys or pam_unix_auth has returned a failure, the user is denied access through rlogin.

Chapter 18 Using SASL

This chapter includes information about the Simple Authentication and Security Layer (SASL).

• SASL (Overview)

• SASL (Reference)

SASL (Overview)

The Simple Authentication and Security Layer (SASL) is a framework that provides authentication and optional security services to network protocols. An application calls the SASL library, /usr/lib/libsasl.so, which provides a glue layer between the application and the various SASL mechanisms. The mechanisms are used in the authentication process and in providing optional security services. The version of SASL delivered with the Solaris 10 release is derived from the Cyrus SASL with a few changes.

SASL provides the following services:

• Loading of any plug-ins

• Determining the necessary security options from the application to aid in the choice of a security mechanism

• Listing of plug-ins that are available to the application

• Choosing the best mechanism from a list of available mechanisms for a particular authentication attempt

• Routing the authentication data between the application and the chosen mechanism

• Providing information about the SASL negotiation back to the application

SASL (Reference)

The following section provides information about the implementation of SASL for the Solaris 10 release.

SASL Plug-ins

SASL plug-ins provide support for security mechanisms, user-canonicalization, and auxiliary property retrieval. By default, the dynamically loaded 32-bit plug-ins are installed in /usr/lib/sasl, and the 64-bit plug-ins are installed in /usr/lib/sasl/$ISA. The following security mechanism plug-ins are provided in the Solaris 10 release:

crammd5.so.1

CRAM-MD5, which supports authentication only, no authorization

digestmd5.so.1

DIGEST-MD5, which supports authentication, integrity, and privacy, as well as authorization

gssapi.so.1

GSSAPI, which supports authentication, integrity, and privacy, as well as authorization. The GSSAPI security mechanism requires a functioning Kerberos infrastructure.

plain.so.1

PLAIN, which supports authentication and authorization.

In addition, the EXTERNAL security mechanism plug-in and the INTERNAL user canonicalization plug-ins are built into libsasl.so.1. The EXTERNAL mechanism supports authentication and authorization. The mechanism supports integrity and privacy if the external security source provides it. The INTERNAL plug-in adds the realm name if necessary to the username.

The Solaris 10 release is not supplying any auxprop plug-ins at this time. For the CRAM-MD5 and DIGEST-MD5 mechanism plug-ins to be fully operational on the server side, the user must provide an auxprop plug-in to retrieve clear text passwords. The PLAIN plug-in requires additional support to verify the password. The support for password verification can be one of the following: a callback to the server application, an auxprop plug-in, saslauthd, or pwcheck. The salauthd and pwcheck daemons are not provided in the Solaris releases. For better interoperability, restrict server applications to those mechanisms that are fully operational by using the mech_list SASL option.

SASL Environment Variable

By default, the client authentication name is set to getenv("LOGNAME"). This variable can be reset by the client or by the plug-in.

SASL Options

The behavior of libsasl and the plug-ins can be modified on the server side by using options that can be set in the /etc/sasl/app.conf file. The variable app is the server-defined name for the application. The documentation for the server app should specify the application name.

The following options are supported in the Solaris 10 release:

auto_transition

Automatically transitions the user to other mechanisms when the user does a successful plain text authentication.

auxprop_login

Lists the name of auxiliary property plug-ins to use.

canon_user_plugin

Selects the canon_user plug-in to use.

mech_list

Lists the mechanisms that are allowed to be used by the server application.

pwcheck_method

Lists the mechanisms used to verify passwords. Currently, auxprop is the only allowed value.

reauth_timeout

Sets the length of time, in minutes, that authentication information is cached for a fast reauthentication. This option is used by the DIGEST-MD5 plug-in. Setting this option to 0 disables reauthentication.

The following options are not supported in the Solaris 10 release:

plugin_list

Lists available mechanisms. Not used because the option changes the behavior of the dynamic loading of plugins.

saslauthd_path

Defines the location of the saslauthd door, which is used for communicating with the saslauthd daemon. The saslauthd daemon is not included in the Solaris 10 release. So, this option is also not included.

keytab

Defines the location of the keytab file used by the GSSAPI plug-in. Use the KRB5_KTNAME environment variable instead to set the default keytab location.

The following options are options not found in Cyrus SASL. However, they have been added for the Solaris 10 release:

use_authid

Acquire the client credentials rather than use the default credentials when creating the GSS client security context. By default, the default client Kerberos identity is used.

log_level

Sets the desired level of logging for a server.

Chapter 19 Using Solaris Secure Shell (Tasks)

Solaris Secure Shell enables a user to securely access a remote host over an unsecured network. The shell provides commands for remote login and remote file transfer. The following is a list of topics in this chapter.

• Solaris Secure Shell (Overview)

• Solaris Secure Shell and the OpenSSH Project

• Configuring Solaris Secure Shell (Task Map)

• Using Solaris Secure Shell (Task Map)

For reference information, see Chapter 20, Solaris Secure Shell (Reference). For information on the relationship of Solaris Secure Shell to the OpenSSH project, see Solaris Secure Shell and the OpenSSH Project.

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.

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.

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, http://www.sun.com/bigadmin/home/index.jsp. 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

Solaris Secure Shell and the OpenSSH Project

The Solaris Secure Shell is a fork of the OpenSSH project. Security fixes for vulnerabilities that are discovered in later versions of OpenSSH are integrated into Solaris Secure Shell, as are individual bug fixes and features. Internal development continues on the Solaris Secure Shell fork.

While Sun engineers provide bug fixes to the project, they have also integrated the following Solaris features into the Solaris fork of Secure Shell:

• PAM - Solaris Secure Shell uses PAM. The OpenSSH UsePAM configuration option is not supported.

• Privilege separation - Solaris Secure Shell does not use the privilege separation code from the OpenSSH project. Solaris Secure Shell separates the processing of auditing, record keeping and re-keying from the processing of the session protocols.

  Solaris Secure Shell privilege separation code is always on and cannot be switched off. The OpenSSH UsePrivilegeSeparation option is not supported.

• Locale - Solaris Secure Shell fully supports language negotiation as defined in RFC 4253, Secure Shell Transfer Protocol. After the user logs in, the user's login shell profile can override the Solaris Secure Shell negotiated locale settings.

• Auditing - Solaris Secure Shell is fully integrated into the Solaris auditing subsystem. For information on auditing, see Part VII, Solaris Auditing.

• GSS-API support - GSS-API can be used for user authentication and for initial key exchange. The GSS-API is defined in RFC4462, Generic Security Service Application Program Interface.

• Proxy commands - Solaris Secure Shell provides proxy commands for SOCKS5 and HTTP protocols. For an example, see How to Set Up Default Connections to Hosts Outside a Firewall.

In the Solaris Express Community Edition and the OpenSolaris releases, Solaris Secure Shell resyncs the SSH_OLD_FORWARD_ADDR compatibility flag from the OpenSSH project. As of March 2009, the Solaris Secure Shell version is 1.3.

Solaris Secure Shell (Task Map)

The following task map points to task maps for configuring Solaris Secure Shell and for using Solaris Secure Shell.

Configuring Solaris Secure Shell (Task Map)

The following task map points to procedures for configuring Solaris Secure Shell.

Configuring Solaris Secure Shell

By default, host-based authentication and the use of both protocols are not enabled in Solaris Secure Shell. Changing these defaults requires administrative intervention. Also, for port forwarding to work requires administrative intervention.

How to Set Up Host-Based Authentication for Solaris Secure Shell

The following procedure sets up a public key system where the client's public key is used for authentication on the server. The user must also create a public/private key pair.

In the procedure, the terms client and local host refer to the machine where a user types the ssh command. The terms server and remote host refer to the machine that the client is trying to reach.

1. Assume the Primary Administrator role, or become superuser.

   The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

2. On the client, enable host-based authentication.

   In the client configuration file, /etc/ssh/ssh_config, type the following entry:

   HostbasedAuthentication yes

   For the syntax of the file, see the ssh_config(4) man page

3. On the server, enable host-based authentication.

   In the server configuration file, /etc/ssh/sshd_config, type the same entry:

   HostbasedAuthentication yes

   For the syntax of the file, see the sshd_config(4) man page

4. On the server, configure a file that enables the client to be recognized as a trusted host.

   For more information, see the FILES section of the sshd(1M) man page.

   • Add the client as an entry to the server's /etc/ssh/shosts.equiv file.

     client-host

   • Or, you can instruct users to add an entry for the client to their ~/.shosts file on the server.

     client-host

5. On the server, ensure that the sshd daemon can access the list of trusted hosts.

   Set IgnoreRhosts to no in the /etc/ssh/sshd_config file.

   ## sshd_config IgnoreRhosts no

6. Ensure that users of Solaris Secure Shell at your site have accounts on both hosts.

7. Do one of the following to put the client's public key on the server.

   • Modify the sshd_config file on the server, then instruct your users to add the client's public host keys to their ~/.ssh/known_hosts file.

     ## sshd_config IgnoreUserKnownHosts no

     For user instructions, see How to Generate a Public/Private Key Pair for Use With Solaris Secure Shell.

   • Copy the client's public key to the server.

     The host keys are stored in the /etc/ssh directory. The keys are typically generated by the sshd daemon on first boot.

     1. Add the key to the /etc/ssh/ssh_known_hosts file on the server.

        On the client, type the command on one line with no backslash.

        # cat /etc/ssh/ssh_host_dsa_key.pub | ssh RemoteHost \ 'cat >> /etc/ssh/ssh_known_hosts && echo "Host key copied"'

     2. When you are prompted, supply your login password.

        When the file is copied, the message “Host key copied” is displayed.

        Each line in the /etc/ssh/ssh_known_hosts file consists of fields that are separated by spaces:

        hostnames algorithm-name publickey comment

     3. Edit the /etc/ssh/ssh_known_hosts file and add RemoteHost as the first field in the copied entry.

        ## /etc/ssh/ssh_known_hosts File RemoteHost <copied entry>

Example 19–1 Setting Up Host-based Authentication

In the following example, each host is configured as a server and as a client. A user on either host can initiate an ssh connection to the other host. The following configuration makes each host a server and a client:

• On each host, the Solaris Secure Shell configuration files contain the following entries:

  ## /etc/ssh/ssh_config HostBasedAuthentication yes # ## /etc/ssh/sshd_config HostBasedAuthentication yes IgnoreRhosts no

• On each host, the shosts.equiv file contains an entry for the other host:

  ## /etc/ssh/shosts.equiv on machine2 machine1

  ## /etc/ssh/shosts.equiv on machine1 machine2

• The public key for each host is in the /etc/ssh/ssh_known_hosts file on the other host:

  ## /etc/ssh/ssh_known_hosts on machine2 … machine1

  ## /etc/ssh/ssh_known_hosts on machine1 … machine2

• Users have an account on both hosts:

  ## /etc/passwd on machine1 jdoe:x:3111:10:J Doe:/home/jdoe:/bin/sh

  ## /etc/passwd on machine2 jdoe:x:3111:10:J Doe:/home/jdoe:/bin/sh

How to Enable Solaris Secure Shell v1

This procedure is useful when a host interoperates with hosts that run v1 and v2.

1. Assume the Primary Administrator role, or become superuser.

   The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

2. Configure the host to use both Solaris Secure Shell protocols.

   Edit the /etc/ssh/sshd_config file.

   # Protocol 2 Protocol 2,1

3. Provide a separate file for the host key for v1.

   Add a HostKey entry to the /etc/ssh/sshd_config file.

   HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key HostKey /etc/ssh/ssh_host_rsa1_key

4. Generate a host key for v1.

   # ssh-keygen -t rsa1 -f /etc/ssh/ssh_host_rsa1_key -N ''

   -t rsa1

   Indicates the RSA algorithm for v1.

   -f

   Indicates the file that holds the host key.

   -N ''

   Indicates that no passphrase is required.

5. Restart the sshd daemon.

   # svcadm restart network/ssh:default

   You can also reboot the system.

How to Configure Port Forwarding in Solaris Secure Shell

Port forwarding enables a local port be forwarded to a remote host. Effectively, a socket is allocated to listen to the port on the local side. Similarly, a port can be specified on the remote side.

Solaris Secure Shell port forwarding must use TCP connections. Solaris Secure Shell does not support UDP connections for port forwarding.

1. Assume the Primary Administrator role, or become superuser.

   The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

2. Configure a Solaris Secure Shell setting on the remote server to allow port forwarding.

   Change the value of AllowTcpForwarding to yes in the /etc/ssh/sshd_config file.

   # Port forwarding AllowTcpForwarding yes

3. Restart the Solaris Secure Shell service.

   remoteHost# svcadm restart network/ssh:default

   For information on managing persistent services, see Chapter 16, Managing Services (Overview), in System Administration Guide: Basic Administration and the svcadm(1M) man page.

4. Verify that port forwarding can be used.

   remoteHost# /usr/bin/pgrep -lf sshd 1296 ssh -L 2001:remoteHost:23 remoteHost

How to Create User and Host Exceptions to SSH System Defaults

This procedure adds a conditional Match block after the global section of the /etc/ssh/sshd_config file. Keyword-value pairs that follow the Match block specify exceptions for the user, group, host, or address that is specified as the match.

1. Assume the Primary Administrator role, or become superuser.

   The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

2. Edit the sshd_config file.

3. Configure a user, group, host, or address to use different SSH keyword settings from the default settings.

   Place the Match blocks after the global settings.

   ---

   Note –

   The global section of the file might or might not list the default settings. For the defaults, see the sshd_config(4) man page.

   ---

   You might have users who should not be allowed to use TCP forwarding. In the following example, any user in the group public, and any user name that begins with test cannot use TCP forwarding:

   ## sshd_config file ## Global settings # Example (reflects default settings): # # Host * # ForwardAgent no # ForwardX11 no # PubkeyAuthentication yes # PasswordAuthentication yes # FallBackToRsh no # UseRsh no # BatchMode no # CheckHostIP yes # StrictHostKeyChecking ask # EscapeChar ~ Match Group public AllowTcpForwarding no Match User test* AllowTcpForwarding no

   For information about the syntax of the Match block, see the sshd_config(4) man page.

Using Solaris Secure Shell (Task Map)

The following task map points to user procedures for using Solaris Secure Shell.

Using Solaris Secure Shell

Solaris Secure Shell provides secure access between a local shell and a remote shell. For more information, see the ssh_config(4) and ssh(1) man pages.

How to Generate a Public/Private Key Pair for Use With Solaris Secure Shell

Users must generate a public/private key pair when their site implements host-based authentication or user public-key authentication. For additional options, see the ssh-keygen(1) man page.

Before You Begin

Determine from your system administrator if host-based authentication is configured.

1. Start the key generation program.

   myLocalHost% ssh-keygen -t rsa Generating public/private rsa key pair. …

   where -t is the type of algorithm, one of rsa, dsa, or rsa1.

2. Specify the path to the file that will hold the key.

   By default, the file name id_rsa, which represents an RSA v2 key, appears in parentheses. You can select this file by pressing the Return key. Or, you can type an alternative file name.

   Enter file in which to save the key (/home/jdoe/.ssh/id_rsa):<Press Return>

   The file name of the public key is created automatically by appending the string .pub to the name of the private key file.

3. Type a passphrase for using your key.

   This passphrase is used for encrypting your private key. A null entry is strongly discouraged. Note that the passphrase is not displayed when you type it in.

   Enter passphrase (empty for no passphrase): <Type passphrase>

4. Retype the passphrase to confirm it.

   Enter same passphrase again: <Type passphrase> Your identification has been saved in /home/jdoe/.ssh/id_rsa. Your public key has been saved in /home/jdoe/.ssh/id_rsa.pub. The key fingerprint is: 0e:fb:3d:57:71:73:bf:58:b8:eb:f3:a3:aa:df:e0:d1 jdoe@myLocalHost

5. Check the results.

   Check that the path to the key file is correct.

   % ls ~/.ssh id_rsa id_rsa.pub

   At this point, you have created a public/private key pair.

6. Choose the appropriate option:

   • If your administrator has configured host-based authentication, you might need to copy the local host's public key to the remote host.

     You can now log in to the remote host. For details, see How to Log In to a Remote Host With Solaris Secure Shell.

     1. Type the command on one line with no backslash.

        % cat /etc/ssh/ssh_host_dsa_key.pub | ssh RemoteHost \ 'cat >> ~./ssh/known_hosts && echo "Host key copied"'

     2. When you are prompted, supply your login password.

        Enter password: <Type password> Host key copied %

   • If your site uses user authentication with public keys, populate your authorized_keys file on the remote host.

     1. Copy your public key to the remote host.

        Type the command on one line with no backslash.

        myLocalHost% cat $HOME/.ssh/id_rsa.pub | ssh myRemoteHost \ 'cat >> .ssh/authorized_keys && echo "Key copied"'

     2. When you are prompted, supply your login password.

        When the file is copied, the message “Key copied” is displayed.

        Enter password: Type login password Key copied myLocalHost%

7. (Optional) Reduce the prompting for passphrases.

   For a procedure, see How to Reduce Password Prompts in Solaris Secure Shell. For more information, see the ssh-agent(1) and ssh-add(1) man pages.

Example 19–2 Establishing a v1 RSA Key for a User

In the following example, the user can contact hosts that run v1 of the Solaris Secure Shell protocol. To be authenticated by v1 hosts, the user creates a v1 key, then copies the public key portion to the remote host.

myLocalHost% ssh-keygen -t rsa1 -f /home/jdoe/.ssh/identity
Generating public/private rsa key pair.
…
Enter passphrase (empty for no passphrase): <Type passphrase>
Enter same passphrase again: <Type passphrase>
Your identification has been saved in /home/jdoe/.ssh/identity.
Your public key has been saved in /home/jdoe/.ssh/identity.pub.
The key fingerprint is:
…
myLocalHost% ls ~/.ssh
id_rsa
id_rsa.pub
identity
identity.pub
myLocalHost% cat $HOME/.ssh/identity.pub | ssh myRemoteHost \
'cat >> .ssh/authorized_keys && echo "Key copied"'

How to Change the Passphrase for a Solaris Secure Shell Private Key

The following procedure does not change the private key. The procedure changes the authentication mechanism for the private key, the passphrase. For more information, see the ssh-keygen(1) man page.

1. Change your passphrase.

   Type the ssh-keygen command with the -p option, and answer the prompts.

   myLocalHost% ssh-keygen -p Enter file which contains the private key (/home/jdoe/.ssh/id_rsa):<Press Return> Enter passphrase (empty for no passphrase): <Type passphrase> Enter same passphrase again: <Type passphrase>

   where -p requests changing the passphrase of a private key file.

How to Log In to a Remote Host With Solaris Secure Shell

1. Start a Solaris Secure Shell session.

   Type the ssh command, and specify the name of the remote host.

   myLocalHost% ssh myRemoteHost

   A prompt questions the authenticity of the remote host:

   The authenticity of host 'myRemoteHost' can't be established. RSA key fingerprint in md5 is: 04:9f:bd:fc:3d:3e:d2:e7:49:fd:6e:18:4f:9c:26 Are you sure you want to continue connecting(yes/no)?

   This prompt is normal for initial connections to remote hosts.

2. If prompted, verify the authenticity of the remote host key.

   • If you cannot confirm the authenticity of the remote host, type no and contact your system administrator.

     Are you sure you want to continue connecting(yes/no)? no

     The administrator is responsible for updating the global /etc/ssh/ssh_known_hosts file. An updated ssh_known_hosts file prevents this prompt from appearing.

   • If you confirm the authenticity of the remote host, answer the prompt and continue to the next step.

     Are you sure you want to continue connecting(yes/no)? yes

3. Authenticate yourself to Solaris Secure Shell.

   1. When prompted, type your passphrase.

      Enter passphrase for key '/home/jdoe/.ssh/id_rsa': <Type passphrase>

   2. When prompted, type your account password.

      jdoe@myRemoteHost's password: <Type password> Last login: Fri Jul 20 14:24:10 2001 from myLocalHost myRemoteHost%

4. Conduct transactions on the remote host.

   The commands that you send are encrypted. Any responses that you receive are encrypted.

5. Close the Solaris Secure Shell connection.

   When you are finished, type exit or use your usual method for exiting your shell.

   myRemoteHost% exit myRemoteHost% logout Connection to myRemoteHost closed myLocalHost%

How to Reduce Password Prompts in Solaris Secure Shell

If you do not want to type your passphrase and your password to use Solaris Secure Shell, you can use the agent daemon. Start the daemon at the beginning of the session. Then, store your private keys with the agent daemon by using the ssh-add command. If you have different accounts on different hosts, add the keys that you need for the session.

You can start the agent daemon manually when needed, as described in the following procedure.

1. Start the agent daemon.

   myLocalHost% eval `ssh-agent` Agent pid 9892

2. Verify that the agent daemon has been started.

   myLocalHost% pgrep ssh-agent 9892

3. Add your private key to the agent daemon.

   Type the ssh-add command.

   myLocalHost% ssh-add Enter passphrase for /home/jdoe/.ssh/id_rsa: <Type passphrase> Identity added: /home/jdoe/.ssh/id_rsa(/home/jdoe/.ssh/id_rsa) myLocalHost%

4. Start a Solaris Secure Shell session.

   myLocalHost% ssh myRemoteHost

   You are not prompted for a passphrase.

Example 19–3 Using ssh-add Options

In this example, jdoe adds two keys to the agent daemon. The -l option is used to list all keys that are stored in the daemon. At the end of the session, the -D option is used to remove all the keys from the agent daemon.

myLocalHost% ssh-agent
myLocalHost% ssh-add
Enter passphrase for /home/jdoe/.ssh/id_rsa: <Type passphrase>
Identity added: /home/jdoe/.ssh/id_rsa(/home/jdoe/.ssh/id_rsa)
myLocalHost% ssh-add /home/jdoe/.ssh/id_dsa
Enter passphrase for /home/jdoe/.ssh/id_dsa: <Type passphrase>
Identity added:
/home/jdoe/.ssh/id_dsa(/home/jdoe/.ssh/id_dsa)

myLocalHost% ssh-add -l
md5 1024 0e:fb:3d:53:71:77:bf:57:b8:eb:f7:a7:aa:df:e0:d1
/home/jdoe/.ssh/id_rsa(RSA)
md5 1024 c1:d3:21:5e:40:60:c5:73:d8:87:09:3a:fa:5f:32:53
/home/jdoe/.ssh/id_dsa(DSA)

User conducts Solaris Secure Shell transactions

myLocalHost% ssh-add -D
Identity removed:
/home/jdoe/.ssh/id_rsa(/home/jdoe/.ssh/id_rsa.pub)
/home/jdoe/.ssh/id_dsa(DSA)

How to Use Port Forwarding in Solaris Secure Shell

You can specify that a local port be forwarded to a remote host. Effectively, a socket is allocated to listen to the port on the local side. The connection from this port is made over a secure channel to the remote host. For example, you might specify port 143 to obtain email remotely with IMAP4. Similarly, a port can be specified on the remote side.

Before You Begin

To use port forwarding, the administrator must have enabled port forwarding on the remote Solaris Secure Shell server. For details, see How to Configure Port Forwarding in Solaris Secure Shell.

1. To use secure port forwarding, choose one of the following options:

   • To set a local port to receive secure communication from a remote port, specify both ports.

     Specify the local port that listens for remote communication. Also, specify the remote host and the remote port that forward the communication.

     myLocalHost% ssh -L localPort:remoteHost:remotePort

   • To set a remote port to receive a secure connection from a local port, specify both ports.

     Specify the remote port that listens for remote communication. Also, specify the local host and the local port that forward the communication.

     myLocalHost% ssh -R remotePort:localhost:localPort

Example 19–4 Using Local Port Forwarding to Receive Mail

The following example demonstrates how you can use local port forwarding to receive mail securely from a remote server.

myLocalHost% ssh -L 9143:myRemoteHost:143 myRemoteHost 

This command forwards connections from port 9143 on myLocalHost to port 143. Port 143 is the IMAP v2 server port on myRemoteHost. When the user launches a mail application, the user needs to specify the local port number, as shown in the following dialog box.

Do not confuse localhost in the dialog box with myLocalHost. myLocalHost is a hypothetical host name. localhost is a keyword that identifies your local system.

Example 19–5 Using Remote Port Forwarding to Communicate Outside of a Firewall

This example demonstrates how a user in an enterprise environment can forward connections from a host on an external network to a host inside a corporate firewall.

myLocalHost% ssh -R 9022:myLocalHost:22 myOutsideHost

This command forwards connections from port 9022 on myOutsideHost to port 22, the sshd server, on the local host.

myOutsideHost% ssh -p 9022 localhost
myLocalHost%

How to Copy Files With Solaris Secure Shell

The following procedure shows how to use the scp command to copy encrypted files between hosts. You can copy encrypted files either between a local host and a remote host, or between two remote hosts. The command operates similarly to the rcp command, except that the scp command prompts for authentication. For more information, see the scp(1) man page.

You can also use the sftp, a more secure form of the ftp command. For more information, see the sftp(1) man page. For an example, see Example 19–6.

1. Start the secure copy program.

   Specify the source file, the user name at the remote destination, and the destination directory.

   myLocalHost% scp myfile.1 jdoe@myRemoteHost:~

2. Supply your passphrase when prompted.

   Enter passphrase for key '/home/jdoe/.ssh/id_rsa': <Type passphrase> myfile.1 25% |******* | 640 KB 0:20 ETA myfile.1

   After you type the passphrase, a progress meter is displayed. See the second line in the preceding output. The progress meter displays:

   • The file name

   • The percentage of the file that has been transferred

   • A series of asterisks that indicate the percentage of the file that has been transferred

   • The quantity of data transferred

   • The estimated time of arrival, or ETA, of the complete file (that is, the remaining amount of time)

Example 19–6 Specifying a Port When Using the sftp Command

In this example, the user wants the sftp command to use a specific port. The user uses the -o option to specify the port.

% sftp -o port=2222 guest@RemoteFileServer

How to Set Up Default Connections to Hosts Outside a Firewall

You can use Solaris Secure Shell to make a connection from a host inside a firewall to a host outside the firewall. This task is done by specifying a proxy command for ssh either in a configuration file or as an option on the command line. For the command-line option, see Example 19–7.

In general, you can customize your ssh interactions through a configuration file.

• You can customize either your own personal file in ~/.ssh/config.

• Or, you can use the settings in the administrative configuration file, /etc/ssh/ssh_config.

The files can be customized with two types of proxy commands. One proxy command is for HTTP connections. The other proxy command is for SOCKS5 connections. For more information, see the ssh_config(4) man page.

1. Specify the proxy commands and hosts in a configuration file.

   Use the following syntax to add as many lines as you need:

   [Host outside-host] ProxyCommand proxy-command [-h proxy-server] \ [-p proxy-port] outside-host|%h outside-port|%p

   Host outside-host

   Limits the proxy command specification to instances when a remote host name is specified on the command line. If you use a wildcard for outside-host, you apply the proxy command specification to a set of hosts.

   proxy-command

   Specifies the proxy command.

   The command can be either of the following:

   • /usr/lib/ssh/ssh-http-proxy-connect for HTTP connections

   • /usr/lib/ssh/ssh-socks5-proxy-connect for SOCKS5 connections

   -h proxy-server and -p proxy-port

   These options specify a proxy server and a proxy port, respectively. If present, the proxies override any environment variables that specify proxy servers and proxy ports, such as HTTPPROXY, HTTPPROXYPORT, SOCKS5_PORT, SOCKS5_SERVER, and http_proxy. The http_proxy variable specifies a URL. If the options are not used, then the relevant environment variables must be set. For more information, see the ssh-socks5-proxy-connect(1) and ssh-http-proxy-connect(1) man pages.

   outside-host

   Designates a specific host to connect to. Use the %h substitution argument to specify the host on the command line.

   outside-port

   Designates a specific port to connect to. Use the %p substitution argument to specify the port on the command line. By specifying %h and %p without using the Host outside-host option, the proxy command is applied to the host argument whenever the ssh command is invoked.

2. Run Solaris Secure Shell, specifying the outside host.

   For example, type the following:

   myLocalHost% ssh myOutsideHost

   This command looks for a proxy command specification for myOutsideHost in your personal configuration file. If the specification is not found, then the command looks in the system-wide configuration file, /etc/ssh/ssh_config. The proxy command is substituted for the ssh command.

Example 19–7 Connecting to Hosts Outside a Firewall From the Command Line

How to Set Up Default Connections to Hosts Outside a Firewall explains how to specify a proxy command in a configuration file. In this example, a proxy command is specified on the ssh command line.

% ssh -o'Proxycommand=/usr/lib/ssh/ssh-http-proxy-connect \
-h myProxyServer -p 8080 myOutsideHost 22' myOutsideHost

The -o option to the ssh command provides a command-line method of specifying a proxy command. This example command does the following:

• Substitutes the HTTP proxy command for ssh

• Uses port 8080 and myProxyServer as the proxy server

• Connects to port 22 on myOutsideHost

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.

• A Typical Solaris Secure Shell Session

• Client and Server Configuration in Solaris Secure Shell

• Keywords in Solaris Secure Shell

• Maintaining Known Hosts in Solaris Secure Shell

• Solaris Secure Shell Packages and Initialization

• Solaris Secure Shell Files

• Solaris Secure Shell Commands

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:

1. 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.

2. When data transfer is complete, the user program terminates.

3. 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.

4. 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.

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:

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.

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

Solaris Secure Shell Commands

The following table summarizes the major Solaris Secure Shell commands.

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.