B    Secure Shell

The Secure Shell software is client/server software that provides a suite of secure network commands that you can use in addition to or in place of traditional nonsecure network commands. Table B-1 describes the traditional nonsecure network commands and the equivalent Secure Shell commands.

Table B-1:  Traditional Nonsecure Network Commands and Secure Shell Commands

Task Traditional Nonsecure Network Command Secure Shell Command
Execute commands on a remote system rsh ssh2
Log in to a remote system rlogin or telnet ssh2
Transfer files between systems rcp or ftp scp2 or sftp2

This appendix contains the following information:

B.1    Secure Shell Servers and Clients

A Secure Shell server is a system on which the Secure Shell server software is installed and the Secure Shell sshd2 daemon is started. The Secure Shell software includes the Secure Shell server software that runs on a system running the Tru64 UNIX Version 5.1A or higher operating system software. The remainder of this appendix refers to a Secure Shell server as server.

A Secure Shell client is a system on which the Secure Shell client software is installed. The Secure Shell software includes the Secure Shell client software that runs on a system running the Tru64 UNIX Version 5.1A or higher operating system software.

The Secure Shell client software provides the Secure Shell scp2, sftp2, and ssh2 commands and other Secure Shell commands to manage the Secure Shell client software. The remainder of this appendix refers to a Secure Shell client as client.

By default, the Tru64 UNIX Secure Shell server and client software are installed when you upgrade to or install the Tru64 UNIX Version 5.1B or higher software and the following message is displayed during the setld procedure: 

Configuring "Secure Shell Base Components" (OSFSSHBASEnnn) 
Creating ./etc/ssh2/ssh2_config 
Creating ./etc/ssh2/sshd2_config 
Creating ./etc/ssh2/ssh_dummy_shell.out 
Generating 1024-bit dsa key pair 
 Key generated. 
1024-bit dsa hostkey 
Private key saved to ./etc/ssh2/hostkey 
Public key saved to ./etc/ssh2/hostkey.pub 
Creating /.ssh2/ssh2_config 
 
Installation of the Secure Shell Base Components (OSFSSHBASEnnn) subset is complete. 
 
 

B.2    Secure Shell Overview

When the server is started, the sshd2 daemon listens on port 22 (by default) for a client to initiate a socket connection. When a client connects, the sshd2 daemon starts a child process. The child process initiates a public host key exchange with the client. The public host key exchange is a process in which the client and server exchange their public host keys to authenticate their identity to each other. A public host key is created on the server as /etc/ssh2/hostkey.pub when you install the Secure Shell software.

The first time a client connects to a server, the user is (by default) prompted to accept a copy of the server's public host key. If the user accepts the key, the server's public host key is copied to the user's hostkeys directory on the client. The client uses this public host key to authenticate the server on subsequent connections. You can also copy the server's public host key in advance to the user's hostkeys directory on the client as key_port_servername.pub. For example, if the server name is orange, copy its key as key_22_orange.pub.

After the client and server authenticate each other, the child process attempts to authenticate the user. The user must have a valid user account and home directory on the server. If the child process fails to authenticate the user, it will refuse the connection. Secure Shell uses one of the following user authentication methods:

After the child process authenticates the user's identity, the actual connection with the client occurs. The connection includes command execution, encrypted data transfer, and termination of the connection. Once the connection is established, all authentication and communication between the client and server will use the Secure Shell connection. When the connection is terminated, the child process started by the sshd2 daemon terminates.

B.3    Configuring the Secure Shell Server and Client

You configure how servers and clients communicate by setting values to keywords in the /etc/ssh2/sshd2_config file for the server and in the /etc/ssh2/ssh2_config file for the client. User's can also have their own $HOME/.ssh2/ssh2_config file on the client, where $HOME is the name of the user's home directory.

The sshd2_config file and the ssh2_config file contain keyword-argument pairs, one per line. Keywords are assigned default values, which you can change. Keywords are case insensitive. Empty lines and lines starting with a number sign ( # ) are ignored as comments.

B.3.1    Configuring the Server

The /etc/ssh2/sshd2_config file (or the file specified with the sshd2 -f command) contains configuration keywords and values that the sshd2 daemon reads when it starts. You can override the values for a keyword in the sshd2_config file by entering the keyword and value on the command line when you start the sshd2 daemon; however, values set this way are reset to the value in the /etc/ssh2/sshd2_config file when the sshd2 daemon restarts.

If you modify the sshd2_config file while the sshd2 daemon is running, you must reset the sshd2 daemon to implement the change. Changes made this way apply only to new client connections. See Section B.6.1 for information on resetting the sshd2 daemon.

Example B-1 is a sample /etc/ssh2/sshd2_config file. See sshd2_config(4) for a description of each keyword in the sshd2_config file.

Example B-1:  Sample sshd2_config File

## sshd2_config
## SSH version Server Configuration File
##
## General
 
	VerboseMode			no
#	QuietMode			yes
	AllowCshrcSourcingWithSubsystems	no
	ForcePTTYAllocation		no
	SyslogFacility			AUTH
#	SyslogFacility			LOCAL7
 
## Network
 
	Port 				22
	ListenAddress			0.0.0.0
	RequireReverseMapping		no
	MaxBroadcastsPerSecond		0
#	MaxBroadcastsPerSecond		1  
#	NoDelay				yes
#	KeepAlive			yes
#	MaxConnections			50
#	MaxConnections			0 
# 0 == number of connections not limited 
 
## Crypto
 
	Ciphers				AnyCipher
#	Ciphers				AnyStd
#	Ciphers				AnyStdCipher
#	Ciphers				3des
	MACs				AnyMAC
#	MACs				AnyStd
#	MACs				AnyStdMAC
#	RekeyIntervalSeconds		3600
 
## User
 
	PrintMotd			yes
	CheckMail			yes
	UserConfigDirectory		"%D/.ssh2"
#	UserConfigDirectory		"/etc/ssh2/auth/%U"
	UserKnownHosts			yes
#	LoginGraceTime			600
#	PermitEmptyPasswords		no
#	StrictModes			yes
 
## User public key authentication
 
	HostKeyFile			hostkey
	PublicHostKeyFile		hostkey.pub
	RandomSeedFile			random_seed
	IdentityFile			identification
	AuthorizationFile		authorization
	AllowAgentForwarding		yes
 
## Tunneling
 
	AllowX11Forwarding		yes
	AllowTcpForwarding		yes
#	AllowTcpForwardingForUsers	sjl, cowboyneal@slashdot.org
#	DenyTcpForwardingForUsers	"2[:isdigit:]*4, peelo"
#	AllowTcpForwardingForGroups	priviliged_tcp_forwarders
#	DenyTcpForwardingForGroups	coming_from_outside
 
## Authentication
## Hostbased and PAM are not enabled by default.
 
#	BannerMessageFile	        /etc/ssh2/ssh_banner_message
#	BannerMessageFile               /etc/issue.net
	PasswordGuesses			1
#	AllowedAuthentications		hostbased,publickey,password
#	AllowedAuthentications		publickey,pam-1@ssh.com
	AllowedAuthentications		hostbased,publickey,password
#	RequiredAuthentications		publickey,password
#	SshPAMClientPath		ssh-pam-client
 
## Host restrictions
 
#	AllowHosts			localhost, foobar.com, friendly.org
#	DenyHosts			evil.org, aol.com
#	AllowSHosts			trusted.host.org
#	DenySHosts			not.quite.trusted.org
#	IgnoreRhosts			no
	IgnoreRhosts			no
#	IgnoreRootRHosts		no
# (the above, if not set, is defaulted to the value of IgnoreRHosts)
 
## User restrictions
 
#	AllowUsers			"sj*,s[:isdigit:]##,s(jl|amza)"
#	DenyUsers			skuuppa,warezdude,31373
#	DenyUsers			don@untrusted.org
#	AllowGroups			staff,users
#	DenyGroups			guest
#	PermitRootLogin			nopwd
	PermitRootLogin			yes
 
## SSH1 compatibility
 
#	Ssh1Compatibility		
#	Sshd1Path			
 
## Chrooted environment
 
#	ChRootUsers			ftp,guest
#	ChRootGroups			guest
 
## subsystem definitions
 
	subsystem-sftp                  sftp-server
 
 

B.3.2    Configuring the Client

The /etc/ssh2/ssh2_config file contains configuration keywords and values that the client software reads when it starts. Each user can also have their own $HOME/.ssh2/ssh2_config file, where $HOME is the name of the user's home directory. The /etc/ssh2/ssh2_config file is read first, then the user's version is read. The last obtained value for a keyword is used, except for the EnforceSecureRutils keyword. See Section B.4 for more information about the EnforceSecureRutils keyword.

Example B-2 is a sample /etc/ssh2/ssh2_config file. See ssh2_config(4) for a description of each keyword in the ssh2_config file.

Example B-2:  Sample ssh2_config File

## ssh2_config
## SSH version Client Configuration File
##
 
## The "*" is used for all hosts, but you can use other hosts as
## well.
*:
 
## Tru64 UNIX specific
# Secure the r* utilities (no, yes)
        EnforceSecureRutils             no
 
## General
 
	VerboseMode			no
#	QuietMode			yes
#	DontReadStdin			no
#	BatchMode			yes
#	Compression			yes
#	ForcePTTYAllocation		yes
#	GoBackground			yes
#	EscapeChar			~
#	PasswordPrompt			"%U@%H's password: "
	PasswordPrompt			"%U's password: "
	AuthenticationSuccessMsg	yes
 
## Network
 
	Port				22
	NoDelay				no
	KeepAlive			yes
#	SocksServer socks://login@socks.ssh.com:1080/11.12.0.0/
16,19.74.23.0/24
 
## Crypto
 
	Ciphers				AnyStdCipher 
	MACs				AnyMAC
	StrictHostKeyChecking           ask	
#	RekeyIntervalSeconds		3600
 
## User public key authentication
 
	IdentityFile			identification
	AuthorizationFile		authorization
	RandomSeedFile			random_seed
 
## Tunneling
 
#	GatewayPorts			yes
#	ForwardX11			yes
#	ForwardAgent			yes
 
# Tunnels that are set up upon logging in
 
#	LocalForward			"110:pop3.ssh.com:110"
#	RemoteForward			"3000:foobar:22"
 
## SSH1 Compatibility
 
   Ssh1Compatibility               yes
	Ssh1AgentCompatibility		none
#	Ssh1AgentCompatibility		traditional
#	Ssh1AgentCompatibility		ssh2
#	Ssh1Path			/usr/local/bin/ssh1			
 
## Authentication 
## Hostbased is not enabled by default.
 
#	AllowedAuthentications		hostbased,publickey,password
	AllowedAuthentications		publickey,password
 
# For ssh-signer2 (only effective if set in the global configuration
# file, usually /etc/ssh2/ssh2_config)
 
#	DefaultDomain			foobar.com
#	SshSignerPath			ssh-signer2
 
## Examples of per host configurations
 
#alpha*:
#	Host				alpha.oof.fi
#	User				user
#	PasswordPrompt			"%U:s password at %H: "
#	Ciphers				idea
 
#foobar:
#	Host				foo.bar
#	User				foo_user
 
 
 

B.4    Configuring Nonsecure Network Commands to Use Secure Shell

You can configure the rsh, rlogin, and rcp commands and applications that use the rcmd() function to automatically use a Secure Shell connection by enabling the EnforceSecureRutils keyword in the /etc/ssh2/ssh2_config file or in a user's $HOME/.ssh2/ssh2_config file. By default, the EnforceSecureRutils keyword is disabled. If the EnforceSecureRutils keyword is enabled in the /etc/ssh2/ssh2_config file, it is enabled for all users overriding the setting in the user's $HOME/.ssh2/ssh2_config file. If the EnforceSecureRutils keyword is disabled in the /etc/ssh2/ssh2_config file, a user can enable it in their $HOME/.ssh2/ssh2_config file.

The following are considerations if you enable the EnforceSecureRutils keyword:

B.5    Configuring Secure Shell User Authentication

You must configure the client and server to use the same type of user authentication, which can be any or all of the following:

You configure the type of user authentication that the client and server use by assigning values to the AllowedAuthentications keyword in the server's /etc/ssh2/sshd2_config file and in the client's /etc/ssh2/ssh2_config file or in the user's $HOME/.ssh2/ssh2_config file. The user authentication methods are used in the order in which they are listed for the AllowedAuthentications keyword. For example, if hostbased is listed first, the server will try hostbased authentication before trying the next listed authentication. The first successful authentication is the one used. By default, the server tries public key authentication, then password authentication.

B.5.1    Configuring Password Authentication

Password authentication requires that a user have a password-protected user account that can be authenticated by a Tru64 UNIX password authentication method. Tru64 UNIX password authentication methods include:

To use password authentication, set the value of the AllowedAuthentications keyword to include password (the default) in the /etc/ssh2/sshd2_config file and in the /etc/ssh2/ssh2_config file; for example: 

AllowedAuthentications 			password

By default, users are allowed only one password attempt. The number of failed password attempts is defined by the value assigned to the PasswordGuesses keyword in the /etc/ssh2/sshd2_config file.

If you change the value of a keyword in the /etc/ssh2/sshd2_config file, you must enter the following command to reset the sshd2 daemon:

# /sbin/init.d/sshd reset

When using password authentication, the password prompt will be displayed on stderr. If stderr is redirected, it might appear that the login command has stopped responding while it waits for the password to be entered.

The way in which users are prompted for their password on a Tru64 UNIX Secure Shell client depends on whether or not a Secure Shell connection is used. If the server is running the sshd daemon, users are prompted as follows: 

username's password:
 

If the server is not running the sshd daemon, users are prompted as follows: 

Password:
 
 

B.5.2    Configuring Public Key Authentication

Public key authentication requires that a user have a pair of keys. A public key and a private key. These keys are used to authenticate the user and to encrypt and decrypt the data exchanged between clients and servers. The public key is published and distributed to the servers with which the user communicates. The private key is kept secret on the local client and never published or distributed. What one public or private key does, only the other associated public or private key can undo.

Public key authentication requires configuration on the client and on the server.

Note

A user's private key and public key are not the same as the server's private host key (/etc/ssh2/hostkey) and public host key (/etc/ssh2/hostkey.pub). The server's private and public host keys were created when you installed the Secure Shell software; they are used to authenticate the server. A user creates private and public keys; they are used to authenticate the user.

B.5.2.1    Configuring Public Key Authentication on the Client

Follow these steps to configure public key authentication on a Tru64 UNIX Secure Shell client:

  1. Set the value of the AllowedAuthentications keyword in the /etc/ssh2/ssh2_config file to include publickey (the default); for example: 

    AllowedAuthentications 		publickey,password

  2. Instruct the user to log in to their user account and create a public and private key pair by entering the ssh-pubkeymgr command. The user will be prompted for the following information: 

    $ ssh-pubkeymgr
Setting host to hostname
Checking for publickey authentication to be enabled in the 
client config..
Your client configuration is all set.
 
Checking for publickey authentication to be enabled in the 
server config..
Your server configuration is all set.
 
Checking for existing user public keys..
Couldn't find your DSA keypair.. I'll generate you a new set..
Running ssh-keygen2... don't forget to give it a passphrase!
 
Generating 1024-bit dsa key pair
   2 OOo.oOo.oOo.
Key generated.
1024-bit dsa, username@hostname.fqdn, date time -0500
Passphrase : secret passphrase [1]
Again      : secret passphrase
Private key saved to $HOME/.ssh2/id_dsa_1024_a
Public key saved to $HOME/.ssh2/id_dsa_1024_a.pub
If you are logging in from this computer, you need to have an
identification file that defines what private keys will be recognized
when you login. By default, this should be id_dsa_1024_a.
 
Creating your identity file..
 
Creating your authorization file..
 
Creating your local host public key..
 
The next section allows you to add hosts that you wish to login 
from using public key authentication. 
 
Do you want to add any hosts to your authorization file? 
(Default: yes) yes [2]
 
Type in user and hostname, press return after each one.
 
Add which user? username 
Add which host? hostname
You added username at servername 
as a trusted login.
Press return to continue or Ctrl-D to exit.
^D
All the new files are in your $HOME/.ssh2 directory.
 
Now that you have your public keypair generated, you can 
copy your public key up to remote hosts so you can login to 
them using public key authentication. You also need to add this key, 
username-hostname.pub,
to the ~/.ssh2/authorization file on the server.
 
Do you want to upload  username-hostname key to a 
remote host? (Default: yes) [3]
Upload to which host? hostname.fqdn
Which user account? username
Now running scp2 to connect to hostname.fqdn..
Most likely you'll have to type a password :)
Host key not found from database.
Key fingerprint:
xolog-bivic-nomeb-behas-zanet-matuc-hedol-moliv-videl-melal-cixox
You can get a public key's fingerprint by running
% ssh-keygen -F publickey.pub on the keyfile.
Are you sure you want to continue connecting (yes/no)? yes
Host key saved to $HOME/.ssh2/hostkeys/key_22_hostname.fqdn.pub
host key for hostname.fqdn, accepted by username date time -0 500
username@hostname.fqdn's password: password [4]
username-hostname.pub |755B|0.7 kB/s|TOC: 00:00:01|100% [5]
 
Press return to upload to more hosts or Ctrl-D to exit.
^D

    1. Enter a passphrase assigned for the keypair. [Return to example]

    2. Enter yes to add a host entry in the authorization file if you will access your user account on the client from a remote host that uses public host key authentication. A host entry identifies the user name and name of a remote host from which you will access your user account on the client.

      If you enter yes, you are prompted for the user name by which you want to be authenticated, then for the name of the remote host. Host names should be entered with their fully qualified domain name (fqdn). For example, if the remote host's name is orange and its fully qualified domain name is color.art.com, enter orange.color.art.com

      A host entry is added to the authorization file in the following format: 

      Key username-hostname.pub

      [Return to example]

    3. Enter yes to copy your public key to a user account on a remote host from which you will access your account on the client. If you enter yes, you are prompted for the name of the remote host and the user account to which your public key will be copied. This is usually the user name and the name of the remote host for which you added a host entry in the authorization file. Host names should be entered with their fully qualified domain name. [Return to example]

    4. The user's public key will be copied to the specified user account on the remote host. Users must enter a password for the specified user account on the remote host because, by default, password authentication is the only authentication available at this time. [Return to example]

    5. A status message is displayed that shows the results of copying the public key to the remote host. [Return to example]

The ssh-pubkeymgr command creates:

B.5.2.2    Configuring Public Key Authentication on the Server

Follow these steps to configure public key authentication on the server:

  1. Set the value of the AllowedAuthentications keyword in the /etc/ssh2/sshd2_config file to include publickey (the default); for example: 

    AllowedAuthentications 		publickey,password

    If you change the value of the AllowedAuthentications keyword, you must enter the following command to reset the sshd2 daemon:

    # /sbin/init.d/sshd reset

  2. If the client and server are not the same system, create a $HOME/.ssh2 directory on the server. ($HOME is the name of the user's home directory for which public key authentication is being configured.)

  3. If necessary, create an authorization file in the user's $HOME/.ssh2 directory. Add to the authorization file a host entry for the client. A host entry identifies the name of a public key for a client from which the user can access their user account on the local host.

    A host entry is added to the authorization file in the following format: 

    Key username-clienthostname.pub

  4. If the user did not upload their public key from the client to the remote server when public key authentication was configured, copy from the client the user's public key file ($HOME/username-hostname.pub) to the user's $HOME/.ssh2 directory on the server.

B.5.2.3    Accessing a Remote Server

Example B-3 shows sample output when logging in to a remote server that is using public key authentication.

Example B-3:  Public Key Authentication Login Output

$ssh server_name
Passphrase for key "/home/user/.ssh2/id_dsa_1024_a
with comment "1024-bit dsa, created by user@Local 
date time +0200":
 
 

B.5.2.4    Restricting User Access

You can restrict a user to execute only certain UNIX commands when a user logs in to a server that is using public key authentication. To restrict users, enter the allowable UNIX command(s) under the Key entry in the user's authorization file on the server. For example, the following entry would use public key authentication to authenticate the user, execute the ls command in the login directory, then return the user to the local host prompt: 

Key username-hostname.pub
Command ls

B.5.2.5    Managing Passphrases

The passphrase is not the user's Tru64 UNIX user account password. The passphrase is the secret text that the user entered with the ssh-pubkeymgr command to create a public and private key pair. The passphrase is used only by the client and server to exchange information about the user.

Users are prompted for the passphrase when they enter a Secure Shell command on a server that uses public key authentication. Users can configure the server so that it does not repeatedly prompt for a user's passphrase during a session by running the Secure Shell agent and loading their private keys into the Secure Shell agent. When the agent is running, all key-related operations are directed to the agent. The Secure Shell agent terminates when the user logs out or stops the Secure Shell agent.

Follow these steps to run the Secure Shell agent:

  1. Log in to the server.

  2. Start the Secure Shell agent:

    ssh-agent2 $SHELL

    The $SHELL environment variable identifies the user's login shell.

    Alternatively, users can automatically start the Secure Shell agent when logging in to the server by adding the ssh-agent2 $SHELL command to their login file; for example, their .login file.

    The Secure Shell agent invokes the specified shell as a child process, and the shell prompt appears.

  3. Load the private keys into the Secure Shell agent:

    $ ssh-add2

    The ssh-add2 command prompts the user for the passphrase.

B.5.3    Configuring Host-Based Authentication

Host-based authentication is an authentication method that is based on system identification, not password or passphrase identification. Clients and servers can use only host-based authentication if both systems are running the Tru64 UNIX operating system software.

Host-based authentication requires:

Because most communication between hosts is reciprocal and a host can be a client and a server, follow these steps on all hosts that will communicate by using host-based authentication:

  1. Set the value of the following keywords in the /etc/ssh2/sshd2_config file:

    If you change the value of a keyword in the /etc/ssh2/sshd2_config file, enter the following command to reset the sshd2 daemon:

    # /sbin/init.d/sshd reset

  2. Set the value of the following keywords in the /etc/ssh2/ssh2_config file or in a user's $HOME/.ssh2/ssh2_config file:

  3. To make local host's public host key available in its /etc/ssh2/knownhosts directory for other hosts to copy when using host-based authentication, enter: 

    # ln -sf /etc/ssh2/hostkey.pub \
/etc/ssh2/knownhosts/hostname.fqdn.ssh-dss.pub

    The hostname is the name of the local host and the fqdn is the fully qualified domain name for the local host as defined in the /etc/hosts file. For example, if the local host name is orange and its fully qualified domain name is color.art.com, enter orange.color.art.com.ssh-dss.pub.

    In a TruCluster Server environment, the cluster alias public host key must be available in the /etc/ssh2/knownhosts directory. Enter the following command to make the cluster alias public host key available: 

    # ln -sf /etc/ssh2/hostkey.pub \
/etc/ssh2/knownhosts/cluster_alias.fqdn.ssh-dss.pub

    The cluster_alias is the name of the cluster alias and the fqdn is the fully qualified domain name for the cluster alias as defined in the /etc/hosts file.

    For a host outside of a TruCluster Server environment to connect to a host inside a TruCluster Server environment, copy the cluster alias public host key file (/etc/ssh2/hostkey.pub) to the /etc/ssh2/knownhosts directory on the host outside of the cluster.

  4. For each user who will use host-based authentication, create a file called .rhosts or .shosts in each user's home directory and add an entry for the local host and an entry for each remote host with which the local host communicates. An entry includes the host name followed by its fully qualified domain name. For example, if the local host name is orange and its fully qualified domain name is color.art.com, enter:

    orange.color.art.com

    The user must be the owner of the .rhosts or .shosts file in their home directory. Use the chown command to set the user as the owner of the .rhosts or .shosts file and to set the permissions to 600 (read and write by owner only).

  5. Make a copy of the public host key file (/etc/ssh2/knownhosts/hostname.fqdn.ssh-dss.pub) from each remote host with which the local host communicates is in the /etc/ssh2/knownhosts directory on the local host.

    To copy public host keys, you use the ssh-hostbased-setup command. The ssh-hostbased-setup command verifies and, if necessary, copies the public host key from the specified remote host or from the remote hosts listed in the specified file to the /etc/ssh2/knownhosts directory on the local host.

    To use the ssh-hostbased-setup command, enter: 

    # ssh-hostbased-setup hostname | filename

    hostname

    Specifies the name of the remote host for which host-based authentication is being configured or verified.

    filename

    Specifies the file that contains the names of remote hosts for which host-based authentication is being configured or verified. The specified file is usually the .rhosts file or the .shost file.

    See ssh-hostbased-setup(1) for more information.

B.6    Managing the Secure Shell Server

This section describes how to:

B.6.1    Starting, Stopping, Restarting, and Resetting the sshd2 Daemon

When the sshd2 daemon starts, it uses the configuration information in the /etc/ssh2/sshd2_config file (the default). When you start the sshd2 daemon, you can specify configuration options on the command line. Command line configuration options override values in the /etc/ssh2/sshd2_config file and are effective only until the sshd2 daemon restarts. To permanently make a configuration change, edit the /etc/ssh2/sshd2_config file. See Section B.3.1 for more information on the /etc/ssh2/sshd2_config file.

B.6.2    Restricting Users to Home Directories

Use the ssh-chrootmgr command to restrict a user to a home directory when the user enters the ssh2 command or the sftp2 command.

Follow these steps to restrict a user to a home directory:

  1. Enter the ssh-chrootmgr command with the name of the users or groups you want to restrict:

    # ssh-chrootmgr username username username

  2. Edit the /etc/ssh2/sshd2_config file and update the value of the ChRootUsers entry to include the restricted users (or the ChRootGroups entry to include the restricted groups) specified in step 1.

  3. Reset the sshd2 daemon:

    # /sbin/init.d/sshd reset

  4. Edit the /etc/passwd file and configure /bin/ssh-dummy-shell as the shell for the restricted users and users in the groups specified in step 1.

See ssh-chrootmgr(1) and ssh-dummy-shell(1) for more information.

B.6.3    Creating a Public and Private Host Key

A public host key and private host key are created when you install the Secure Shell software. You need to create a new public host key and private host key only if you want to change them.

Follow these steps to create a new public host key and private host key:

  1. Stop the sshd2 daemon:

    # /sbin/init.d/sshd stop

  2. Create the host keys:

    # ssh-keygen2 -P /etc/ssh2/hostkey

  3. Start the sshd2 daemon:

    # /sbin/init.d/sshd start

Note

Users who have a copy of the server's old public host key will get a warning message when connecting to a server with a new public host key. Users can delete the server's old public host key file from their hostkeys directory on the client. The next time the client connects to the server, the user will be prompted to accept a copy of the server's new public host key.

B.6.4    Forwarding TCP/IP Ports and X11 Data Through a Secure Shell Connection

You can configure TCP/IP ports and X11 connections to forward data by using a Secure Shell connection.

B.6.4.1    TCP/IP Port Forwarding

Forwarding, or tunneling, is a way to forward otherwise insecure TCP data through a Secure Shell connection. For example, you can configure POP3, SMTP, and HTTP connections to use a Secure Shell connection.

Follow these steps to configure TCP/IP port forwarding:

  1. Set the value of the AllowTcpForwarding keyword to yes in the /etc/ssh2/sshd2_config file (the default).

    If you change the value of the AllowTcpForwarding keyword, you must enter the following command to reset the sshd2 daemon:

    # /sbin/init.d/sshd reset

  2. Configure the TCP/IP port to forward. There are two kinds of TCP/IP port forwarding:

B.6.4.2    X11 Forwarding

Follow these steps to enable X11 forwarding:

  1. Set the value of the ForwardX11 keyword to yes in the /etc/ssh2/sshd2_config file (the default).

    If you change the value of the ForwardX11 keyword, you must enter the following command to reset the sshd2 daemon:

    # /sbin/init.d/sshd reset

  2. Test the connection by logging in to the client and entering an X11 command. For example, to start the X clock program, enter:

    xclock &

    If the X clock window is displayed, X11 forwarding is working.

    Note

    Do not set the DISPLAY variable on the client. Doing so will disable encryption. (X connections forwarded through Secure Shell use a special local display setting.)

B.7    Using the Secure Shell Commands

This section describes how to use Secure Shell commands to:

Note

When a client connects to a server for the first time, the user is prompted to accept a copy of the server's public host key. If the user accepts the key, a copy of the server's public host key is copied to the user's hostkeys directory on the client. The client uses this public host key to authenticate the server on subsequent connects.

B.7.1    Copying Files Between Clients and Servers

You can use the following Secure Shell commands to copy files:

B.7.1.1    Using the scp2 Command

Use the scp2 or scp command on a client to copy files to and from a server. The installation process creates a symbolic link from the scp command executable to the scp2 command executable. The scp2 command runs with normal user privileges.

Relative paths can also be used; they are interpreted relative to the user's home directory.

See scp2(1) for more information about the scp command.

B.7.1.2    Using the sftp2 Command

Use the sftp2 command or the sftp command on a client to copy files to and from a server. The installation process creates a symbolic link from the sftp command executable to the sftp2 command executable.

The sftp2 command functions like the ftp command but does not use the ftp daemon or the ftp client for its connections. The sftp2 command runs with normal user privileges.

To use the sftp2 command to connect to a remote host to copy files, enter: 

sftp2 [options] hostname

You can also use the scp2 syntax with the sftp2 command. See Section B.7.1.1, scp2(1), sftp2(1) for more information.

B.7.2    Logging In and Executing Commands on a Server

Use the ssh2 command or the ssh command on the client to securely log in and execute commands on a server. The installation process creates a symbolic link from the ssh command executable to the ssh2 command executable.

To execute commands on a server, enter: 

ssh2 [options] server_name [command]

When a user successfully logs in to a server, the sshd2 daemon:

  1. Runs with the user's privileges.

  2. Sets up a basic environment.

  3. Changes to the user's home directory.

  4. Runs the user's shell.

See ssh2(1) for more information about the ssh2 command.