Using SSH for Secure Interactive Communications

XCF Virtual Help Session

Table of Contents

• 0. Introduction to SSH
  • 0.1 What the heck is SSH?
  • 0.2 What is it used for?
  • 0.3 How can I get it?
• 1. Basic Use of SSH
  • 1.1 Setup before first use [ssh-keygen]
  • 1.2 Regular use of SSH [ssh]
  • 1.3 Eliminate passwords [identity.pub and authorized_keys]
  • 1.4 Easier use of SSH [ssh-agent and ssh-add]
• 2. Advanced Use of SSH
  • 2.1 Port forwarding
  • 2.2 Configuration options

0. Introduction

0.1 What the heck is SSH?

Secure SHell [SSH] is a set of programs intended to replace and extend the functionality of the insecure "r"-programs: rlogin, rsh and rcp. It does this by employing encryption and authentication, surpassing rlogin's ".rhosts" mechanism with a secure one.

SSH encrypts all data in the connection between the local machine [the machine from which the connection is being made] and the remote machine [the machine which is being connected to]. In addition to encrypting the keystrokes and screen data, SSH will also encrypt and forward X11 connections. In this case, the user does not have to manually set the DISPLAY variable on the remote machine, as SSH will take care of it all automagically.

0.2 What is it used for?

SSH can be used to:

Securely connect to a remote site, preventing your password from being transmitted in the clear across the network.

The most frequent [and perhaps most important] use; password security is of upmost importance, especially with the popularity and relative ease with which brainless morons [ie, crackers] can sniff data off a network. The distributed and cooperative nature of the Internet is good for service and accessibility, but horrible for security... if you want security, you must take steps to make it work, and SSH is a very useful tool to that extent.

To prevent the capture of information typed [or received] across the network from the remote host.

Not as useful... frankly, most people are just boring. But if you want to use PGP, SSH [again from the remote machine], passwd or some other interactive program which requires you to send or receive sensitive information, SSH will keep that data secure as it's being sent from|to the remote machine to|from the local machine over the network.

To securely access otherwise insecure services [such as FTP, HTTP, POP, etc] on the remote machine.

To be fully secure, however, one must look at all the places where their password is sent out over the network [and is thus available for capture by a malicious party]. Besides telnet|rlogin connections, two other common services which require passwords are FTP and POP. In both these cases, the password is sent over the network in clear text. However, SSH includes the ability to use these services in an encrypted manner, thus disallowing the sending of sensitive information over the network.

SSH is currently being deployed across campus. SSH is available on UCB's undergraduate CS machines and socrates.berkeley.edu. As well, uclink[234]?.berkeley.edu will be supporting SSH in the near future. Your local system administrator can be contacted to determine the availability of [or to encourage the installation of] SSH on other machines. The most recent issue of Berkeley Computing & Communications contains an article on SSH in relation to the UCB campus environment.

0.3 How can I get it?

SSH is freely available for UNIX from the SSH Home Page - http://www.cs.hut.fi/ssh/ .

Information about commercial Windows and Mac versions of SSH is available from DataFellows at their F-Secure SSH page - http://www.datafellows.com/f-secure/fclintp.htm .

UCB campus departments should contact WSS Software Distribution for information regarding discounted license pricing.

1. Basic Use of SSH

1.1 Setup before first use [ssh-keygen]

SSH relies on the knowledge of a slight amount of data stored by the user. SSH is based on RSA-encryption, and like all public-key systems, the user needs both a public and private key to use the system; as well, SSH needs a random number generator seed, which is user-specific. The ssh-keygen program generates this data for the user; ssh-keygen generates the following files:

~/.ssh/identity.pub

This is the user's public key. It's not necessary to keep it secret.

~/.ssh/identity

This is the user's private key. As such, it should not be given out to others, and should have the appropriate permissions. It is protected by the passphrase given to ssh-keygen.

~/.ssh/random_seed

This is the random number generator seed. It should be kept secret.

jsled@josh.asynchronous.org$ [~] ssh-keygen
Initializing random number generator...
Generating p:  ................................++ (distance 528)
Generating q:  ...++ (distance 50)
Computing the keys...
Key generation complete.
Enter file in which to save the key (/home/jsled/.ssh/identity): <RETURN>
Enter passphrase: <user-entered passphrase>
Enter the same passphrase again: <same user-entered passphrase>
Your identification has been saved in /home/jsled/.ssh/identity.
Your public key is:
1024 37 570995861311744913699852643840495620503105177916202595981143078740421447
07234725107032716031313676352354759768729079333048192564496060745735388393675040
48251376663323088994798943255485136598021692118911541230193385758280090695891602
5590978882896036684032728595904115093929448135894970165679059780624183271411 jsled@josh.asynchronous.org
Your public key has been saved in /home/jsled/.ssh/identity.pub

The data for the local machine has been created. The same should be done for all accounts from which the user would like to use SSH. In effect, a separate identity [public/private key pair] is created for each account.

The public key is then copied by the user to the remote machine, where is it placed in the file ~/.ssh/authorized_keys; this file can be made public since it only consists of public keys. The file controls access to account on the remote machine. It works in a manner similar to the ~/.rhosts file, since it defines a list of identities which have access to the system. However, it is fundamentally secure, whereas .rhosts [and the whole rlogin/rcp/rsh mechanism] is not. The easiest way to copy this data between machines is to use copy-and-paste and cat, IMHO. FTP, rcp or ssh can also be used to do this.

1.2 Regular use of SSH [ssh]

Notice that I've only described, above, the setup for one of the authentication methods. That's because it's the only one that really should be used. Forget about using .rhosts, .shosts and any of the hosts.equiv stuff... it's just no good, and it's what SSH was created to replace].

The most relevant command form for use of ssh is:

ssh [-l login_name] hostname [command]

jsled@josh.asynchronous.org [~] ssh cafe.berkeley.edu

jsled@josh.asynchronous.org [~] ssh -l joshua cafe.berkeley.edu

The optional command argument is a command to be executed on the remote machine. The output of this single command will be returned, and ssh will exit with the same status as the command on the remote machine. This is similar to use of rsh, but offers the benefits of ssh.

At this point, a connection will be established between the two machines. SSH will set up X11 forwarding from the remote machine to the local machine; any X11 programs started on the remote machine will automagically used this encrypted channel to transmit X11 data. It will appear as a normal, telnet- or rlogin-created connection. Enjoy.

1.4 Easier use of SSH [ssh-agent and ssh-add]

ssh-add

2. Advanced Use of SSH

This section describes some of the more advanced use of SSH. This section is not necessary for everyday use of SSH, but it will make everyday use much easier.

2.1 Port forwarding

SSH supports the ability to forward ports on both the local and remote machines. This allows you to access non-telnet services through an encrypted channel. You can forward a local port to port 110 on another machine, for instance, to securely check POP mail on that machine.

Forwarding local ports is the most useful option. This allows you to specify a local port number which can then be used securely access a remote port. This is the manner by which you can forward port 61234 to port 110 on machine foobar.berkeley.edu; when you point your mail reader to check 'localhost:61234' for POP mail, it will really [securely] be connecting to 'remotehost:110', and the mail reader will get the POP service it expects on the remote machine.

FIXME : The commands for this aren't working out correctly... I'm working on it... - jsled

2.2 Configuration options

There are many configuration options; to see them all with their descriptions, look at the CONFIGURATION FILES section of the man page ssh(1). The more useful options are summarized below.

Host

The name of the host [or hosts, since wildcards '*' and '?' can be used] which the configuration options following this line apply to. The host given on the ssh command line will match against the appropriate Host line of the configuration file.

Compression

One of the other nice things about SSH, in addition to it's security, is that since it replaces telnet and rlogin, it can do whatever it wants with the data... in this case, compress it. The Compression option allows the user to specify the level of compression to be used on connections with the given host. The possible values are an integer in the range [1,9], which correspond to the same GNU GZIP values.

EscapeChar

Specifies the escape character for ssh to use for the connection. By default this is "~". You can also set this to "^]" to get the normal telnet|rlogin escape sequence, or set it to ``none'' to get a session which is "transparent for binary data" [quote from ssh(1)], meaning you can use it for transfering with kermit, rz, sz, etc.

HostName

Specifies the actualy hostname of the machine to connect to. This allows you to specify an alias or shortcut for a host with the Host config option, specify that alias|shortcut on the command line, and still have it connect to the correct machine. In addition, an IP address can be used for you to give a name to machines-that-have-no-name.

KeepAlive

Allows control of keepalive messages between the machines. Without keepalives, if the network or remote machine goes down, you won't notice until you try and type a command in, because the session will simply stay there. If keepalives are enabled, SSH will notice if either machine or the network goes down. However, if the network route is temporarily down [as is liable to happen on the Internet, these days], the connection will close, as well.

User

Specifies the username to use for logging into this host. This frees you from having to enter the "-l username" option on the ssh command line.