Introduction to SSH

ssh, short for "secure shell," is intended to be a substitute for the Berkeley r-commands (rsh, rlogin, rcp), but has some additional capabilities. This document will cover the steps for setting up ssh for use, including the setup of these additional capabilities, but will not go into much detail on how ssh actually works. The official OpenSSH FAQ answers most common questions about ssh and has pointers to other information resources as well.

One of the best reasons for using ssh is security. Everything that ssh sends across the network is encrypted. This ensures complete privacy, making it extremely difficult for anyone to intercept and record your network traffic. (However, ssh is only as secure as you make it. If you use telnet, rsh, ftp, or any other insecure protocol, that information will be visible across the non-ssh-based connection.) Add the fact that hosts change their encryption keys hourly, and you have a host-to-host communication system that’s extremely hard to beat. ssh functions much like rsh in terms of command syntax, which also makes it extremely easy to use.

One of the other great benefits of using ssh is how it handles X connections. Instead of having to manually set the DISPLAY variable on a remote host in order to use X-based software, ssh will do it for you. Also, ssh will automatically manage your ~/.Xauthority file, adding hosts and displays as necessary. This allows the user to restrict access to the local display (using the command xhost -), yet not have to bother with using the arguably cryptic xauth program to grant remote access when using X-based software on remote hosts. Starting an xterm on a remote host is as simple as typing ssh <host> .

Why Telnet Access is Not Allowed

We do not allow telnet access to the CS&E or CSE Labs network. Telnet sends your password across the network in plain readable text, which is easy for hackers to intercept. To access your UNIX account remotely, use SSH, as it encrypts your data before it is transmitted across the network, making the connection more secure than telnet.

()

SSH Tools

Once you have a network connection (whether it is via modem, DSL, cable, etc) you can use a variety of programs to connect to the CS&E or CSE UNIX machines. We do not allow non-secure connections; you must use a program such as SSH. The OpenSSH FAQ provides information about SSH and how to use it.

There are many different versions of SSH available, some are commercial and some are free. Here are a few links to get you started:

For information on graphical access via an SSH connection see the Graphical Access information on our site.

Unix Configuration

Setup (command line)

Remove rm -f ~/.rhosts You won’t be needing it anymore.
chmod go-w ~. This removes write privileges on your home directory for everyone but you.
mkdir ~/.ssh , if it does not already exist. This is the directory where we’ll be storing your ssh keys. Once created, chmod 711 ~/.ssh . It should only be writable by you, and does not need to be readable by anyone but you. However, there are some files which you might want to make available to others, which is why the group and world-executable bits are set.
Generate your ssh key with the command ssh-keygen -b 2048 -t rsa. This will make a 2048-bit RSA key pair. Use the default setting to save the key (hit enter) and be sure to set a passphrase.
Copy your key into the authorized_keys2 file by typing cp ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys2. Any other OpenSSH ssh2-keys can be placed in this file, one per line. SSH1 keys can be placed in ~/.ssh/authorized_keys, one on a line, the same format as SSH v1. Read the ssh-keygen and ssh man pages for more information on sshv1 key usage.
Make a link from your private key id_rsa to identity so ssh-add knows that it is your default identity file. To do this type ln -s ~/.ssh/id_rsa ~/.ssh/identity.
Optionally chmod 644 ~/.ssh/*.pub . This will allow someone else access to the public half of your ssh key, should they want it for something. Securing the public half is unnecessary, but you should never allow someone access to the other files in your .ssh directory.
Log out, then log back in.
Run ssh-add from a command-line prompt once you’ve logged back in. You should be prompted for your passphrase, if you set one in step 2. If you get a message saying Could not open a connection to your authentication agent, then open a new xterm using your window manager and try again. (Some user configurations spawn xterms just before starting the window manager. These xterms are not children of the window manager, so they do not inherit the connection to ssh-agent.)
Test out ssh by making a connection to a remote host. Use the -v option to enable verbose mode. If you want to run X-based software remotely, you can use the -f option to have ssh return to the command line after spawning the process on the remote host.

Setup (Gnome)

Go to Systems, Preferences, Sessions.
Click on the Startup Programs tab.
Hit 'Add' and type in /usr/bin/ssh-add.
Click 'OK' then 'Close'. Now Gnome should ask you for your ssh passphrase once when you log in and you won't have to enter your passphrase for each ssh connection.

()

Use

Using ssh is simple, and very similar to the way the Berkeley r-commands work.

To simply connect to another host, type:

ssh <hostname>

To connect to a remote host and run a command, type:

ssh <hostname> <command>

To run an X client remotely, the -f option usually works out best:

ssh -f <hostname> <command>

That will establish a connection and, once authentication is complete, will put the ssh connection in the background while the X client starts up.

To copy a file between hosts using ssh, type:

scp <host>:<filea> <fileb>

This would copy filea, located on host host into the local fileb.

Additional Comments

If, for some reason, ssh is unable to use your your ssh identity file to authenticate you, it may ask for your password. It is safe to type your password when prompted by ssh, as all traffic sent by it over the network (including your password!) is encrypted. If ssh is unable to establish a secure connection with the remote host, its default behavior is to fall back to using rsh. If this happens, ssh will warn you with a message saying something like, Secure connection to host.cs.umn.edu refused; reverting to insecure method. Using rsh. WARNING: Connection will not be encrypted. At this point, the standard ~/.rhosts and /etc/hosts.equiv authentication methods are used and, if you’ve followed the steps above to the letter, the connection will fail (you did remove ~/.rhosts didn’t you?). If prompted for your password after seeing the warning above, your password will be sent unencrypted.
Unlike some, the man pages for ssh are relatively easy to understand. There are several possible configuration options not discussed here covered in the man pages. It’s worth the time to check them out.
Some Windows hosts installed and maintained by Systems Staff have ssh client software installed. On the surface, the software works a little differently, but the underlying capabilities are very similar to the Unix version. The Windows client is capable of forwarding X connections, but you must be running an X server on the Windows machine, e.g., Xwin32, in order to support the X clients. It it not possible to ssh into an Windows host at this time; only Unix hosts accept inbound ssh connections.