Configuring Secure Shell (Tasks)

Secure Shell is configured at installation. To change the defaults requires administrative intervention. The following tasks demonstrate how to change some of the defaults.

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.	How to Set Up Host-Based Authentication for Secure Shell
Increase buffer size to handle connection latency.	Raises the value of the TCP property `recv_buf` for high bandwidth, high latency networks.	Changing the TCP Receive Buffer Size in Connecting Systems Using Fixed Network Configuration in Oracle Solaris 11.1
Configure port forwarding.	Enables users to use port forwarding.	How to Configure Port Forwarding in Secure Shell
Configure exceptions to Secure Shell system defaults.	For users, hosts, groups, and addresses, specifies Secure Shell that are different from the system defaults.	How to Create User and Host Exceptions to Secure Shell Defaults
Isolate a `root` environment for `sftp` transfers.	Provides a protected directory for file transfers.	How to Create an Isolated Directory for `sftp` Files

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 assume the root role. For more information, see How to Use Your Assigned Administrative Rights.

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
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
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
```
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
```
Ensure that users of Secure Shell at your site have accounts on both hosts.
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 15-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 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 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 assume the root role. For more information, see How to Use Your Assigned Administrative Rights.

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
```
Restart the Secure Shell service.
```
remoteHost# svcadm restart network/ssh:default
```
For information about managing persistent services, see Chapter 1, Managing Services (Overview), in Managing Services and Faults in Oracle Solaris 11.1 and the svcadm(1M) man page.

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 Secure Shell 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 become an administrator who is assigned the solaris.admin.edit/etc/ssh/sshd_config authorization. By default, the root role has this authorization. For more information, see How to Use Your Assigned Administrative Rights.

Edit the /etc/ssh/sshd_config file.
Configure a user, group, host, or address to use different Secure Shell 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.

How to Create an Isolated Directory for `sftp` Files

This procedure configures an sftponly directory that is created specifically for sftp transfers. Users cannot see any files or directories outside the transfer directory.

Before You Begin

You must assume the root role. For more information, see How to Use Your Assigned Administrative Rights.

On the Secure Shell server, create the isolated directory as a chroot environment.
```
# groupadd sftp
# useradd -m -G sftp -s /bin/false sftponly
# chown root:root /export/home/sftponly
# mkdir /export/home/sftponly/WWW
# chown sftponly:staff /export/home/sftponly/WWW
```
In this configuration, /export/home/sftonly is the chroot directory that only the root account has access to. The user has write permission to the sftponly/WWW subdirectory.

Still on the server, configure a match block for the sftp group.

In the /etc/ssh/sshd_config file, locate the sftp subsystem entry and modify the file as follows:

# pfedit /etc/ssh/sshd_config
...
# sftp subsystem
#Subsystem       sftp    /usr/lib/ssh/sftp-server
Subsystem       sftp    internal-sftp
...
## Match Group for Subsystem
## At end of file, to follow all global options
Match Group sftp
      ChrootDirectory %h
      ForceCommand internal-sftp
      AllowTcpForwarding no

You can use the following variables to specify the chroot path:

%h – Specifies the home directory.
%u – Specifies the username of the authenticated user.
%% – Escapes the % sign.

On the client, verify that the configuration works correctly.

The files in your chroot environment might be different.

root@client:~# ssh sftponly@server
This service allows sftp connections only.
Connection to server closed. No shell access, sftp is enforced.
root@client:~# sftp sftponly@server
sftp> pwd sftp access granted
Remote working directory: /chroot directory looks like root directory
sftp> ls
WWW             local.cshrc     local.login     local.profile
sftp> get local.cshrc
Fetching /local.cshrc to local.cshrc
/local.cshrc    100%  166     0.2KB/s   00:00user can read contents
sftp> put /etc/motd
Uploading /etc/motd to /motd
Couldn't get handle: Permission denieduser cannot write to / directory
sftp> cd WWW
sftp> put /etc/motd
Uploading /etc/motd to /WWW/motd
/etc/motd     100%  118     0.1KB/s   00:00user can write to WWW directory
sftp> ls -l
-rw-r--r--    1 101  10    118 Jul 20 09:07 motdsuccessful transfer
sftp>

Skip Navigation Links
Exit Print View
	Oracle Solaris 11.1 Administration: Security Services Oracle Solaris 11.1 Information Library