Help Home

CSE Home

OpenSSH Secure Shell:

A Brief Tutorial on Setup and Use

Introduction

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 SSH 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> .

Setup

1. Remove rm -f ~/.rhosts You won’t be needing it anymore.

2. chmod go-w ~. This removes write privileges on your home directory for everyone but you.

3. 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.

4. Generate your ssh key with the command ssh-keygen -b 2048 -t dsa. This will make a 2048-bit DSA key pair. Use the default setting to save the key (hit enter) and be sure to set a passphrase.

5. Copy your key into the authorized_keys2 file by typing cp ~/.ssh/id_dsa.pub ~/.ssh/authorized_keys2 . Any other OpenSSH ssh2-keys can be placed in this file, one per line. If a ssh2 key from a non OpenSSH implementation needs to be used from a remote site, read the directions for Using non-openssh ssh2 keys (below). 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 manpages for more information on sshv1 key usage.

6. Make a link from your private key id_dsa to identity so ssh-add knows that it is your default identity file. To do this type ln -s ~/.ssh/id_dsa ~/.ssh/identity .

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

8. Edit your ~/.xinitrc  or ~/.xsession  script. Find the line that starts your window manager and prepend ssh-agent to it. For example, if you use the fvwm2 window manager, change the line that starts fvwm2 to ssh-agent fvwm2 . Your window manager will run as a child process of the agent, which will allow it (and any of its children) to use the agent for authentication purposes.

9. Log out, then log back in.

10. 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.)

11. 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.

Using non-openssh ssh2 keys

You are advised to create a new private/public keypair in all instances, since conversion of a ssh2 key pair doesn’t completely work. This is information for when you are coming from another site with ssh2 keys. ssh1 public keys can just be dropped into ~/.ssh/authorized_keys. whereas non OpenSSH ssh2 keys need something done to them before being put in ~/.ssh/authorized_keys2. If your ssh2 key is an OpenSSH key, it can go right into ~/.ssh/authorized_keys2.

1. Run ssh-keygen -i and tell it where your public ssh2 key is.

2. Put the output of ssh-keygen into the ~/.ssh/authorized_keys2 file on a new line, as one single line.

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 manpages for ssh are relatively easy to understand. There are several possible configuration options not discussed here covered in the manpages. 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.

Please direct questions or comments about the content of this document to Systems Staff.