Sun Microsystems, Inc.
spacer |
black dot
  Previous   Contents   Next 
Chapter 4

Using Secure Shell (Tasks)

This chapter covers the following topics:

Introduction to Secure Shell

Secure Shell allows a user to securely access a remote host over an unsecured network. Authentication is provided by the use of passwords, public keys, or both. All network traffic is encrypted. Thus, Secure Shell prevents a would-be intruder from being able to read an intercepted communication or from spoofing the system.

Secure Shell provides commands for remote login and remote file transfer. Secure Shell can also be used as an on-demand virtual private network (VPN) to forward X Window system traffic or individual port numbers between the local machines and remote machines over the encrypted network link.

With 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 the 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. As a result, Version 1 is deprecated and is provided only to assist users who are migrating to Version 2. Users are strongly discouraged from using Version 1.

Note - Hereafter in this text, v1 is used to represent Version 1, and v2 is used to represent Version 2.

The requirements for Secure Shell authentication are as follows:

  • User authentication - A user can be authenticated through either of the following:

    • Passwords - The user supplies the account password as in the login process.

    • Public keys - The user can create a public/private key pair that is stored on the local host. The remote hosts are provided with the public key, which is required to complete the authentication.

      The source host maintains the private key, and target hosts are provided with the public key that is needed to complete authentication. Public key authentication is a stronger authentication mechanism than password authentication, because the private key never travels over the network. The public/private key pair is stored in the user's home directory under the .ssh subdirectory. The following table shows the default names for the identity files, which store the public keys and private keys.

      Table 4-1 Naming Conventions for Identity Files

      Private Key, Public Key

      Cipher and Protocol Version


      RSA v1


      RSA v2


      DSA v2

  • Host authentication - Host authentication requires the remote host to have access to the local host's public key. A copy of the local host's public key is stored in $HOME/.ssh/known_hosts on the remote host.

The following table shows the authentication methods, the compatible protocol versions, the local host and remote host requirements, and the relative security. Note that the default method is password-based authentication.

Table 4-2 Authentication Methods for Secure Shell

Authentication Method (Protocol Version)

Local Host Requirements

Remote Host Requirements

Security Level

Password-based (v1 or v2)

user account

user account


RSA/DSA public key (v2)

user account

private key in $HOME/.ssh/id_rsa or $HOME/.ssh/id_dsa

public key in $HOME/.ssh/ or $HOME/.ssh/

user account

user's public key ( or ) in $HOME/.ssh/authorized_keys


RSA public key (v1)

user account

private key in $HOME/.ssh/identity

public key in $HOME/.ssh/

user account

user's public key ( ) in $HOME/.ssh/authorized_keys


.rhosts with RSA (v1)

user account

user account

local host name in /etc/hosts.equiv, /etc/shosts.equiv, $HOME/.rhosts, or $HOME/.shosts

local host public key in $HOME/.ssh/known_hosts or /etc/ssh/ssh_known_hosts


.rhosts only (v1 or v2)

user account

user account

local host name in /etc/hosts.equiv, /etc/shosts.equiv, $HOME/.rhosts, or $HOME/.shosts


Using Secure Shell (Task Map)



For Instructions

Create a public/private key pair

Using public/private key pairs is the preferred method for authenticating yourself and encrypting your communications.

"How to Create a Public/Private Key Pair"

Log in with Secure Shell Encrypted Secure Shell communication is enabled by logging in remotely through a process similar to using rsh.

"How to Log In to Another Host with Secure Shell"

Log in without a password with Secure Shell

You can log in using Secure Shell without having to provide a password by using ssh-agent. The ssh-agent command can be run manually or from a startup script.

"How to Log in With No Password While Using ssh-agent"

"How to Set ssh-agent to Run Automatically"

Port forwarding in Secure Shell

You can specify a local port or a remote port to be used in a Secure Shell connection. 

"How to Use Secure Shell Port Forwarding"

Copy files with Secure Shell 

You can copy remote files securely.

"How to Copy Files With Secure Shell"

Transfer files with Secure Shell 

You can log into a remote host with Secure Shell by using transfer commands similar to ftp.

"Transferring Files Remotely Using sftp"

Connect from a host inside a firewall to a host on the outside

Secure shell provides commands compatible with HTTP or SOCKS5 that can be specified in a configuration file or on the command line.

"How to Set Up Default Connections to Hosts Outside a Firewall"

"Example -- Connecting to Hosts Outside a Firewall From the Command Line"

Using Secure Shell

How to Create a Public/Private Key Pair

The standard procedure for creating a Secure Shell public/private key pair follows. For information on additional options, see ssh-keygen(1).

  1. Start the key generation program.

    myLocalHost% ssh-keygen
    Generating public/private rsa key pair.
    Enter file in which to save the key(/home/johndoe/.ssh/id_rsa): 
  2. Enter 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 Return. Or, you can type an alternative filename.

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

    The public key name is created automatically and the string .pub is appended to the private key name.

  3. Enter a passphrase for using your key.

    This passphrase is used for encrypting your private key. A good passphrase is 10-30 characters long, mixes alphabetic and numeric characters, and avoids simple English prose and English names. A null entry means no passphrase is used, but this entry is strongly discouraged for user accounts. Note that the passphrase is not displayed when you type it in.

    Enter passphrase(empty for no passphrase):  <Type the passphrase>
  4. Re-enter the passphrase to confirm it.

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

    The key fingerprint (a colon-separated series of 2 digit hexadecimal values) is displayed. Check that the path to the key is correct. In the example, the path is /home/johndoe/.ssh/ At this point, you have created a public/private key pair.

  6. Copy the public key and append the key to the $HOME/.ssh/authorized_keys file in your home directory on the remote host.

  Previous   Contents   Next