JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle Solaris Administration: Security Services     Oracle Solaris 11 Information Library
search filter icon
search icon

Document Information

Preface

Part I Security Overview

1.  Security Services (Overview)

Part II System, File, and Device Security

2.  Managing Machine Security (Overview)

3.  Controlling Access to Systems (Tasks)

4.  Virus Scanning Service (Tasks)

5.  Controlling Access to Devices (Tasks)

6.  Using the Basic Audit Reporting Tool (Tasks)

7.  Controlling Access to Files (Tasks)

Part III Roles, Rights Profiles, and Privileges

8.  Using Roles and Privileges (Overview)

9.  Using Role-Based Access Control (Tasks)

10.  Security Attributes in Oracle Solaris (Reference)

Part IV Cryptographic Services

11.  Cryptographic Framework (Overview)

12.  Cryptographic Framework (Tasks)

13.  Key Management Framework

Part V Authentication Services and Secure Communication

14.  Network Services Authentication (Tasks)

15.  Using PAM

16.  Using SASL

17.  Using Secure Shell (Tasks)

Secure Shell (Overview)

Secure Shell Authentication

Secure Shell in the Enterprise

Secure Shell and the OpenSSH Project

Secure Shell and FIPS-140 Support

Secure Shell (Task Map)

Configuring Secure Shell (Tasks)

Configuring Secure Shell (Task Map)

How to Set Up Host-Based Authentication for Secure Shell

How to Configure Port Forwarding in Secure Shell

How to Create User and Host Exceptions to SSH System Defaults

Using Secure Shell (Tasks)

Using Secure Shell (Task Map)

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

How to Change the Passphrase for a Secure Shell Private Key

How to Log In to a Remote Host With Secure Shell

How to Reduce Password Prompts in Secure Shell

How to Use Port Forwarding in Secure Shell

How to Copy Files With Secure Shell

How to Set Up Default Connections to Hosts Outside a Firewall

18.  Secure Shell (Reference)

Part VI Kerberos Service

19.  Introduction to the Kerberos Service

20.  Planning for the Kerberos Service

21.  Configuring the Kerberos Service (Tasks)

22.  Kerberos Error Messages and Troubleshooting

23.  Administering Kerberos Principals and Policies (Tasks)

24.  Using Kerberos Applications (Tasks)

25.  The Kerberos Service (Reference)

Part VII Auditing in Oracle Solaris

26.  Auditing (Overview)

27.  Planning for Auditing

28.  Managing Auditing (Tasks)

29.  Auditing (Reference)

Glossary

Index

Configuring Secure Shell (Tasks)

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

Configuring Secure Shell (Task Map)

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

Task
Description
For Instructions
Configure host-based authentication.
Configures host-based authentication on the client and server.
Configure port forwarding.
Enables users to use port forwarding.
Configure exceptions to SSH system defaults.
For users, hosts, groups, and addresses, specifies SSH settings that are different from the system defaults.

How to Set Up Host-Based Authentication for 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.

Before You Begin

You must be in the root role.

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

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

  3. 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
  4. 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
  5. Ensure that users of Secure Shell at your site have accounts on both hosts.
  6. 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 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 17-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:

How to Configure Port Forwarding in 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.


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


Before You Begin

You must be in the root role.

  1. Configure a 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
  2. Restart the Secure Shell service.
    remoteHost# svcadm restart network/ssh:default

    For information about managing persistent services, see Chapter 6, Managing Services (Overview), in Oracle Solaris Administration: Common Tasks and the svcadm(1M) man page.

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

Before You Begin

You must be in the root role.

  1. Edit the sshd_config file.
  2. 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.