Chapter 5 Using Secure Shell (Tasks)

This chapter covers the following topics:

• Introduction to Secure Shell

• Using Secure Shell (Task Map)

• Using Secure Shell

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.

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 5–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.

Using Secure Shell (Task Map)

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/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

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/id_rsa.pub. 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.

How to Log In to Another Host with Secure Shell

1. Use the ssh command, specifying the name of the remote host.

   myLocalHost% ssh myRemoteHost

   The first time you run ssh, a prompt questions the authenticity of the remote host, as follows.

   The authenticity of host 'myRemoteHost' can't be established. RSA key fingerprint in md5 is: 04:9f:bd:fc:3d:3e:d2:e7:49:fd:6e:18:4f:9c:26 Are you sure you want to continue connecting(yes/no)?

   This prompt is normal, and you should type yes and continue. If you have used ssh in the past on this remote host and this warning message still appears, then there might be a breach in your security.

2. Enter the Secure Shell passphrase and the account password when you are prompted for them.

   Enter passphrase for key '/home/johndoe/.ssh/id_rsa': <Return> johndoe@myRemoteHost's password: <Return> Last login: Fri Jul 20 14:24:10 2001 from myLocalHost myRemoteHost%

   Conduct any transactions on the remote host. Any commands that you send and any responses that are received are encrypted.

   ---

   Note –

   If you wish to subsequently change your passphrase, use ssh-keygen with the -p option.

   ---

3. When you are finished with your remote session, type exit or use your usual method for exiting your shell.

   myRemoteHost% exit myRemoteHost% logout Connection to myRemoteHost closed myLocalHost%

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

If you want to omit passphrase and password entry when you are using Secure Shell, you can use the agent daemon. Use the ssh-agent command at the beginning of the session. Then, store your private keys with the agent by using ssh-add. If you have different accounts on different hosts, add those keys that you intend to use in the session. You can start the agent manually when needed as described in the following procedure. Or, you can set the agent to run automatically at the start of every session as described in How to Set ssh-agent to Run Automatically.

1. Start the agent daemon.

   The ssh-agent command starts the agent daemon and displays its process ID.

   myLocalHost% eval `ssh-agent` Agent pid 9892 myLocalHost%

2. Add your private key to the agent daemon.

   The ssh-add command adds your private key to the agent daemon so that subsequent Secure Shell activity will not prompt you for the passphrase.

   myLocalHost% ssh-add Enter passphrase for /home/johndoe/.ssh/id_rsa: Identity added: /home/johndoe/.ssh/id_rsa(/home/johndoe/.ssh/id_rsa) myLocalHost%

3. Start a Secure Shell session.

   myLocalHost% ssh myRemoteHost

Example—Using ssh-add Options

You can use ssh-add to add other keys to the daemon as well. For example, you might concurrently have DSA v2, RSA v2, and RSA v1 keys. To list all keys that are stored in the daemon, use the -l option. To delete a single key from the daemon, use the -d option. To delete all keys, use the -D option.

myLocalHost% eval `ssh-agent`
Agent pid 3347
myLocalHost% ssh-add
Enter passphrase for /home/johndoe/.ssh/id_rsa:
Identity added: /home/johndoe/.ssh/id_rsa(/home/johndoe/.ssh/id_rsa)
myLocalHost% ssh-add /home/johndoe/.ssh/id_dsa
Enter passphrase for /home/johndoe/.ssh/id_dsa: <type passphrase>
Identity added:
/home/johndoe/.ssh/id_dsa(/home/johndoe/.ssh/id_dsa)
myLocalHost% ssh-add -l
md5 1024 0e:fb:3d:53:71:77:bf:57:b8:eb:f7:a7:aa:df:e0:d1
/home/johndoe/.ssh/id_rsa(RSA)
md5 1024 c1:d3:21:5e:40:60:c5:73:d8:87:09:3a:fa:5f:32:53
/home/johndoe/.ssh/id_dsa(DSA)
myLocalHost% ssh-add -d
Identity removed:
/home/johndoe/.ssh/id_rsa(/home/johndoe/.ssh/id_rsa.pub)
/home/johndoe/.ssh/id_dsa(DSA)

How to Set ssh-agent to Run Automatically

If you want to avoid providing your passphrase and password whenever you use Secure Shell, you can start an agent daemon (ssh-agent) by using the .dtprofile script.

1. To start the agent daemon automatically, add the following lines to the end of the $HOME/.dtprofile script:

   if [ "$SSH_AUTH_SOCK" = "" -a -x /usr/bin/ssh-agent ]; then eval `/usr/bin/ssh-agent` fi

2. To terminate the Secure Shell agent daemon when you exit the CDE session, add the following to the $HOME/.dt/sessions/sessionexit script:

   if [ "$SSH_AGENT_PID" != "" -a -x /usr/bin/ssh-agent ]; then /usr/bin/ssh-agent -k fi

   This entry ensures that no one can use the Secure Shell agent after the CDE session is terminated.

3. Start a Secure Shell session.

   myLocalHost% ssh myRemoteHost

   There is no prompt for a passphrase.

How to Use Secure Shell Port Forwarding

You can specify a local port to be forwarded to a remote host. Effectively, a socket is allocated to listen to the port on the local side. The connection from this port is made over a secure channel to the remote host. For example, you might specify port 143 to obtain email remotely with IMAP4. Similarly, a port can be specified on the remote side.

1. To set a local port to be forwarded, specify the local port to listen to, and the remote host and port to forward to.

   myLocalHost% ssh -L localPort:remoteHost:remotePort

2. To set a remote port to receive a secure connection, specify the remote port to listen to, and the local host and port to forward to.

   myLocalHost% ssh -R remotePort:localHost:localPort

Example—Using Local Port Forwarding to Receive Mail

The following example demonstrates how you can use local port forwarding to receive mail securely from a remote server.

myLocalHost% ssh -L 9143:myRemoteHost:143 myRemoteHost 

This command forwards connections to port 9143 on myLocalHost to port 143 (the IMAP v2 server port) on myRemoteHost. When the user launches a mail application, he or she needs to specify the local port number. An example that uses the dtmail command is shown in Figure 5–1.

Note that the term localhost in this case and in Example—Using Remote Port Forwarding to Communicate Outside of a Firewall refers to the keyword that designates the user's local host. localhost should not be confused with myLocalHost, the hypothetical host name that is used to identify a local host in the examples in this chapter.

Figure 5–1 Specifying Port Forwarding for Email

Example—Using Remote Port Forwarding to Communicate Outside of a Firewall

This example demonstrates how a user in an enterprise environment can forward connections from a host on an external network to a host inside a corporate firewall.

myLocalHost% ssh -R 9022:myLocalHost:22 myOutsideHost

This command forwards connections to port 9022 on myOutsideHost to port 22 (the sshd server) on the local host.

myOutsideHost% ssh -p 9022 localhost
myLocalHost%

This command demonstrates how after the remote forwarding connection has been established, the user can use ssh to connect securely from the remote host.

How to Copy Files With Secure Shell

Use the scp command to copy encrypted files between hosts. You can copy encrypted files between either a local and remote host, or between two remote hosts. The command operates similarly to the rcp command except that it prompts for passwords. See scp(1) for more information.

1. Start the secure copy program.

   Specify the source file, user name at remote destination, and destination directory.

   myLocalHost% scp myfile.1 johndoe@myRemoteHost:~

2. Type the Secure Shell passphrase when prompted.

   Enter passphrase for key '/home/johndoe/.ssh/id_rsa': <Return> myfile.1 25% |******* | 640 KB 0:20 ETA myfile.1

   After you type the passphrase, the progress meter is displayed. See the second line in the preceeding output. The progress meter displays:

   • the file name

   • the percentage of the file that has been transferred at this point

   • a series of asterisks that are analogous to the percentage transferred

   • the quantity of data transferred

   • the estimated time of arrival (ETA) of the complete file (that is, the remaining amount of time)

Transferring Files Remotely Using sftp

The sftp command works similarly to ftp but uses a different set of commands. The following table lists some representative commands.

How to Set Up Default Connections to Hosts Outside a Firewall

You can use Secure Shell to make a connection from a host inside a firewall to a host on the other side of the firewall. This task is done by specifying a proxy command for ssh either in a configuration file or as an option on the command line. For more information see Example—Connecting to Hosts Outside a Firewall From the Command Line.

In general, you can customize your ssh interactions through a configuration file, either your own personal file $HOME/.ssh/config or an administrative configuration file in /etc/ssh/ssh_config. See ssh_config(4). There are two types of proxy commands. One proxy command is for HTTP connections. The other proxy command is for SOCKS5 connections.

1. Specify the proxy commands and hosts in a configuration file.

   Use the following syntax to add as many lines as you need:

   [Host outside_host] ProxyCommand proxy_command [-h proxy_server] \ [-p proxy_port] outside_host|%h outside_port|%p

   Use the Host outside_host option to limit this proxy command specification to instances when this host (or hosts if a wildcard is used) is specified on the command line.

   The designation proxy_command can be replaced by either of the following:

   • /usr/lib/ssh/ssh-http-proxy-connect for HTTP connections

   • /usr/lib/ssh/ssh-socks5-proxy-connect for SOCKS5 connections

   The -h proxy_server and -p proxy_port options specify a proxy server and a proxy port, respectively. If present, they override any environment variables that specify proxy servers and ports, such as HTTPPROXY, HTTPPROXYPORT, http_proxy (for specifying a URL), SOCKS5_SERVER, and SOCKS5_PORT. If the options are not used, then the relevant environment variables must be set. See ssh-socks5-proxy-connect(1) and ssh-http-proxy-connect(1).

   Use outside_host to designate a specific host to connect to or use %h to specify the host on the command line. Use outside_port or %p to specify the port. Specifying %h and %p without using the Host outside_host option has the effect of applying the proxy command to the host argument whenever ssh is invoked.

2. Run Secure Shell, specifying the outside host.

   For example, type:

   myLocalHost% ssh myOutsideHost

   This command looks for a proxy command specification for myOutsideHost in your personal configuration file. If not found, then the command looks in the system-wide configuration file, ssh_config. The proxy command is substituted for ssh.

Example—Connecting to Hosts Outside a Firewall From the Command Line

The -o option for ssh lets you type any line that is permitted in an ssh configuration file. In this case the proxy command specification from the previous task is used.

Specify the proxy commands and hosts in a configuration file.

Run ssh and include a proxy command specification as a -o option. For example, type:

% ssh -o'Proxycommand=/usr/lib/ssh/ssh-http-proxy-connect \
-h myProxyServer -p 8080 myOutsideHost 22' myOutsideHost

This command substitutes the HTTP proxy command for ssh, uses port 8080 and myProxyServer as the proxy server, and connects to port 22 on myOutsideHost.