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
    identity, identity.pub	RSA v1
    id_rsa, id_rsa.pub	RSA v2
    id_dsa, id_dsa.pub	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	Medium
RSA/DSA public key (v2)	user account  private key in $HOME/.ssh/id_rsa or $HOME/.ssh/id_dsa public key in $HOME/.ssh/id_rsa.pub or $HOME/.ssh/id_dsa.pub	user account  user's public key (id_rsa.pub or id_dsa.pub ) in $HOME/.ssh/authorized_keys	Strong
RSA public key (v1)	user account  private key in $HOME/.ssh/identity public key in $HOME/.ssh/identity.pub	user account  user's public key (identity.pub ) in $HOME/.ssh/authorized_keys	Strong
.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	Medium
.rhosts only (v1 or v2)	user account	user account  local host name in /etc/hosts.equiv, /etc/shosts.equiv, $HOME/.rhosts, or $HOME/.shosts	Weak