Phil Hurvitz

Securing UNIX Servers with the Secure Shell (ssh)

Because a substantial amount of GIS users are still running UNIX servers and as the Internet becomes more vulnerable to compromises in security, some tools have recently become available to add a higher degree of security to UNIX client/server environments.

This paper discusses the use of one of these tools, the secure shell (ssh). Discussion includes installation and running of the ssh daemon, as well as the use of Windows and UNIX ssh clients.


General Overview

What does any of this have to do with GIS?!

What this paper is (and is not)

Who this paper is for (and is not)

The Secure Shell (ssh)

Conclusion

 


What does any of this have to do with GIS?!

Many organizations, most notably those needing "industrial strength" GIS, still use UNIX

Recent developments in GIS software have focused on Wintel technology, such as the COM components build into ArcInfo 8.X. However, many enterprise GIS solutions still rely quite heavily on UNIX. SDE applications have proven to be most stable under UNIX, and many of the RDBMSs, on which these applications are based, are UNIX-based.


Many components of the Network still rely on UNIX servers

The majority of http and ftp servers that make up the Internet are hosted on UNIX servers. Windows NT and 2000 have proven to provide decent service, but most system administrators still concede that high-end UNIX servers are more stable and scalable than NT servers. In addition, many of the problems experienced on NT (e.g., the LoveBug e-mail virus) are not an issue under UNIX.

The great interest and investment in Linux will also continue to propel UNIX well into the century. Security will continue to be an issue.

 


What this paper is

What this paper is not

For more general or specific discussions of UNIX security, try news:comp.infosystems.security.

 

For all the details, see http://www.ssh.com.

 


Who this paper is for

System administrators have an obligation to their users and to the larger community to take reasonable steps to secure their networks. ssh is a fairly low-effort, but high-benefit method of introducing a high level of security.

 

If you are using UNIX machines for services such as ftp and telnet, and you would prefer not to pass your user-id and password across insecure channels, you should investigate a tool such as ssh.

 

Who this paper is not for

UNIX security experts will most likely have more knowledge of securing their networks than is presented here. This information is geared more toward the occasional UNIX administrator. This role of combined GIS user and UNIX system administrator is common within the GIS community. Until fairly recently, UNIX was a necessity for high-powered GIS; because of this, many users without adequate training or knowledge of security have been "forced" into the role of system administrator.

 

If you are not using a UNIX machine for direct and interactive access (e.g., ftp, telnet, or any other service that offers an authentication challenge), you are not in danger of losing control of your password. However, if you are using these services, you should be concerned.

 

If you only use UNIX servers in anonymous ftp or web sessions to get or put data, you are not actually logging in as a user with a password. In this case, you need not be concerned with losing control of security under UNIX.

 

 


The Secure Shell (ssh)

Why use ssh?

What is ssh?

How does ssh work?

Setting up ssh

Running the ssh as a process on the UNIX server

User setup (Key generation)

Tunneling other services through ssh

Windows ssh Clients

ssh ftp (or other TCP port) forwarding

 


Why use ssh?

Out-of-the-box UNIX networking is inherently insecure

Why is out-of-the-box UNIX networking inherently insecure? Simply stated, it is because user-IDs and Passwords are sent across the wire in CLEAR TEXT!

Here is an image of the way a typical UNIX TCP/IP client/server process is initiated.

out-of-the-box UNIX networking

Note that the user-id and password are sent across in clear text. Proof of this, for the doubtful, is below.

 

Packet sniffers can easily steal user-ids and passwords.

Use of snoop, sniffit, snort, or other packet sniffers by malicious users compromises the security of the network. In a typical networked configuration, a malicious user can plug into the network with a Linux machine, and snoop network traffic for user-ids and passwords.

network packet sniffer

 

How Insecure is Telnet or ftp?

Any UNIX machine on the subnet can log user-ids and passwords from ftp or telnet sessions.

This example uses snoop running on a Solaris 7 machine. A user logged in as root runs snoop, and logs the output to a file called snoop.out. This snoop session is run specifically to log traffic to and from the host badass.

cracker starts snoop to capture network packets

 

A different user starts a telnet session from a random machine to the server badass. The typical telnet session requires the user to enter the login-id and password. The data transmitted by the telnet session startup is being sent across the wire in clear text!

user starts a telnet session

 

Here is the output from the snoop session. It needs to be decoded from the binary dump format to text (using snoop -i). The decoded (and edited) snoop output shows the user-id and password in clear text. Crackers will typically set up filters so that only login and password data are logged to the output file. You can see how easy it is to capture the user-ids and passwords from telnet sessions. How many of you are using telnet as the root user?

output of snoop showing clear text user-id and password from telnet session

 

ftp is no more secure than telnet. Here is the decoded and edited output of a snoop session that has detected an ftp session. Again, the user-id and password show up in clear text! When was the last time you used ftp as root?

output of snoop showing clear text user-id and password from ftp session


What is ssh?

With ssh, clear text user-ids and passwords are never sent across the wire.

 

All TCP traffic sent through ssh can be strongly encrypted. As of today (mid-2000), it is practically impossible to break 1024 bit encryption. This means that ssh, if used correctly, is a completely secure method of communicating across the network.

 

ssh provides the same functionality as the traditional communication tools, but with the benefit of added security.

 

When used as a tunnel, ssh provides the same level of security to arbitrary TCP connections. This means that protocols such as ftp, which are inherently insecure, can be given the same strong level of encryption as the ssh channel.


How does ssh work?

 

Here is an image of the way a typical UNIX TCP/IP client/server process is initiated with ssh.


ssh UNIX networking

 

Here is some output of a snooped session where ssh is used, rather than telnet:

The connection is made using ssh

ssh session

 

A snoop does not show either the user-id, password, or the passphrase. The same encryption takes place for any transmissions across the ssh channel.

snoop of ssh session

 


Setting up ssh

Download


download ssh

 


Compile

ssh is built to use standard GNU compiling tools (e.g. GNUmake, gcc). Compiling is usually uneventful.

Make sure to read any explanatory files in the distribution tarballs; this will tell you what options exist for configuration.

compile ssh

 


Enable ssh1 compatibility

If you will be connecting to servers that only run ssh1, or if you are using clients that only use ssh1, you should download and compile both ssh1 and ssh2. It is possible to run ssh2 with ssh1 backwards compatibility. Instructions on how to do this are in the "Quikstart" file in the ssh2 tarball.

Essentially, the process involves altering a few configuration files.

ssh1 compatibility

 


Running the ssh as a process on the UNIX server

ssh can be made to start up in several different ways.

Set up as daemon to start at boot

  1. Create or copy an existing startup script in /etc/init.d

  2. Create a symlink to S... and K... scripts in /etc/rc3.d

  3. Start the sshd daemon

The sshd daemon will respond to incoming ssh requests


Set up as inetd process

  1. Alter the /etc/inet/inetd.conf file:

    ssh stream tcp nowait root /usr/local/sbin/sshd sshd -I

  2. Alter the /etc/inet/services file:

    ssh 22/tcp

  3. Restart the inetd daemon

A new ssh process will start for each client request


"Encase" in TCP Wrappers

  1. Compile with TCP Wrapper support

    ./configure \--with-libwrap=/usr/local/lib/libwrap.a

  2. Alter Makefile

    -I/PATHOF/tcpwrappers
    WRAPLIBS = -L/PATHOF/tcpwrappers -lwrap


  3. Alter /etc/hosts.allow and /etc/hosts.deny, following rules from TCP Wrappers

  4. Run ssh2 as a daemon

Connections will be logged to /var/log/syslog


User setup (Key generation)

Create key pairs

Use the executables ssh-keygen and/or ssh-keygen2 to create private key and public key.

  • Only the owner should have the private key.

  • The public key is available to anyone.

  • Data are encrypted with public key.

  • Decryption is possible only with the private key.

  • The private key is encrypted with the passphrase in case of file system security breach.


Set up important authorization files

Setup of Authorization Files under ssh1

  1. Copy all personal public keys as single lines in ~/.ssh/authorized_keys. An ssh1 connection to the server will read the authorized_keys file and encrypt data with the correct host key.

  2. Make sure that each of the keys occupy only a single line in the file. If you cut-and-paste from one shell to the other, be sure to remove extraneous newlines.


    ssh1 public keys

 

Setup of Authorization Files under ssh2

Edit a few important files in ~/.ssh2. These files will allow correct encryption of data.

The files are authorization and identification.

ssh2 public keys


Copy public keys to remote hosts

The public keys should be copied to the ~/.ssh and ~/.ssh2 directories on remote hosts. The private key should be saved only on the local host.

 


Tunneling other services through ssh

ssh allows arbitrary TCP connections to be forwarded through the secure ssh channel. In this way, the TCP connection is "shielded" by ssh security and encryption.

ssh tunneling

 

Tunneling X11 Through ssh

Tunneling ftp Through ssh

UNIX clients

  1. Set up a forwarded port
    myhost% ssh -L 1234:host:21 host

  2. Establish ftp connection to local port
    myhost% ftp localhost 1234

ftp transmissions take place through encrypted channel

 

Windows clients

Use client's tcp forwarding (discussed later for each Windows client)

 


Windows ssh Clients


TeraTerm

MindTerm

SSH Secure Shell

Others exist. See http://www.slurping.com/ssh.html

 


TeraTerm

 

TeraTerm Startup

TeraTerm ssh1 authentication uses the local private key and passphrase.

TeraTerm ssh authentication

 

The interface is a typical terminal session, much like any familiar telnet.

TeraTerm ssh session

 

TeraTerm Port Forwarding

Port forwarding is easy and straightforward.

TeraTerm port forward setup

 

Any forwarded ports can be viewed, edited, or deleted.

Simply checking the "X Forwarding" box will redirect X11 displays to a local X11 server such as eXceed or ReflectionX.

TeraTerm port forward listing

 


MindTerm

 

MindTerm Startup

MindTerm shows the version(s) of ssh running on the server.

MIndTerm startup

 

Authentication requires the passphrase.

MindTerm authentication

 

Once authenticated, MindTerm functions much like any familiar terminal session.

MindTerm session

 

MindTerm Port Forwarding

MindTerm's interface for setting up port forwarding takes a little more knowledge of port numbers on UNIX hosts.

MindTerm port forwarding setup

 

MindTerm Secure Copy (scp)

MindTerm also has an interface for secure copying of files. Files can be copied either direction. Recursive copying can copy entire directories between client and host.

MindTerm scp

 

MindTerm's scp has a progress indicator for each file that is transferred.

MindTerm scp progress


SSH Secure Shell

 

 

SSH Secure Shell Startup

SSH Secure Shell starts without a connection.

SSH ssh startup

 

Authentication can use normal UNIX password, but across encrypted channel.

SSH password

 

If no password is provided, and keys & files on host are set up properly, SSH Secure Shell will ask for the passphrase to decrypt the private key.

SSH passphrase authentication

 

After authentication, SSH Secure Shell functions like other terminal clients.

SSH session

 

SSH Secure Shell X11 forwarding

If X11 support is compiled in, and if a local X11 server (e.g., eXceed, ReflectionX) is running, the DISPLAY will automatically be set. DISPLAY will be host:N.0 (where N > 0). The local X11 server will act as a proxy for host:N.0.

SSH automatic env variables

 

Starting a process that spawns an X display will automatically forward the X display to the local X server.

start an X display on the remote host

X display is started

 

The X display will open on the local X server. The DISPLAY will continue to be set correctly for subsequent connections from child shells.

the X display automatically starts on the local X11 server

 

SSH Secure Shell ftp (or other port) forwarding

Port forwarding, as well as other settings, is set up in general settings.

SSH outgoing port forwarding

 

Both incoming and outgoing tunnels can be created. Setup is straightforward, but requires knowledge of port numbers for services on server and client.

SSH setup port forwarding

 

Once set, port forwarding can be altered or deleted. Settings are saved from session to session, so it is necessary to set port forwarding only once, unless a change is needed.

SSH show forwarded ports

 

SSH Secure Shell scp

SSH Secure Shell has an easy and intuitive scp interface. The GUI looks similar to a typical file manager, in which the file system is shown hierarchically. The interface shows the file system for the server.

SSH scp2 GUI

 

Files can be dragged from the client's Windows Explorer.

Windows Explorer

 

Progress of file copying is indicated, along with the transfer rate.

SSH scp2 progress

 


ssh ftp (or other TCP port) forwarding

Using ssh tunnels for ftp is easy, once the tunnel has been established.

  1. Create an ssh local port redirection to the ftp port on remote host

  2. Use Windows ftp client

  3. Connect to localhost (127.0.0.1)

    WS-FTP setup to localhost

  4. Use local port from redirection (e.g. 1200) and Passive Mode for transfer.

    WS-FTP setup ports and Passive Mode

  5. Once the connection is made, ftp functions exactly as expected, but the data transfers occur across an encrypted channel.

    WS-FTP session attached to local port buf forwarded to ssh server

 


Conclusion

As the Internet grows in size and number of users, expect security to become more of an issue.

Using ssh can greatly increase the security of your network.

Setting up and using ssh is fairly straightforward.

Cost-to-benefit ratio for security is high. Software is free; the only cost associated is administrator and user effort.

 


Phil Hurvitz (phurvitz@u.washington.edu, http://lobo.cfr.washington.edu/~phurvitz)
GIS Specialist
College of Forest Resources (http://www.cfr.washington.edu)
355 Bloedel Hall
Box 352100
University of Washington (http://www.washington.edu)
Seattle, WA USA 98195-2100
206.685.8197