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
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 |
Using Secure Shell (Task Map)
Task | Description | For Instructions |
|---|---|---|
Create a public/private key pair | Using public/private key pairs is the preferred method for authenticating yourself and encrypting your communications. | |
| Log in with Secure Shell | Encrypted Secure Shell communication is enabled by logging in remotely through a process similar to using rsh. | |
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. | |
Port forwarding in Secure Shell | You can specify a local port or a remote port to be used in a Secure Shell connection. | |
| Copy files with Secure Shell | You can copy remote files securely. | |
| Transfer files with Secure Shell | You can log into a remote host with Secure Shell by using transfer commands similar to ftp. | |
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).
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):
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.
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>
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/id_rsa.pub. The key fingerprint is: 0e:fb:3d:57:71:73:bf:58:b8:eb:f3:a3:aa:df:e0:d1 johndoe@myLocalHost
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/id_rsa.pub. At this point, you have created a public/private key pair.
Copy the public key and append the key to the $HOME/.ssh/authorized_keys file in your home directory on the remote host.