SSH (the Secure SHell) is a set of network tools that provides secure alternatives to telnet, rlogin, rsh, rcp, and other Unix programs. There are also versions of SSH available for Windows and Macintosh platforms. SSH provides the means to securely login to other hosts and transfer files between hosts without having to send an unencrypted password over the network where it might be eavesdropped. It also provides the means to encrypt other network traffic, such as X11 traffic, between hosts through SSH tunneling.
How to get SSH
(The off-site links below will open in new browser windows.)
For Unix: A version of SSH that understands Kerberos is installed by default on Facilitized Unix hosts. If you are using a non-Facilitized Unix host, you can get SSH from http://www.openssh.com or download pre-compiled RPMs for Linux from various sources.
For Windows: A recommended SSH client is PuTTY. The PuTTY distribution site also has binaries for command-line scp and SSH clients. CMU Computing Services distributes an SSH client via the myandrew site. Some features of this client do not work with the SCS servers on Facilitized Unix hosts, though it works fine for interactive login sessions.
For MacOS: OpenSSH is included with MacOS X. See http://www.openssh.com for pointers to some other MacOS clients.
Using SSH on Facilitized Unix hosts
Since the SSH on Facilitized Unix hosts understands Kerberos, you can use SSH to login to other Facilitized Unix hosts, copy files between such hosts, and run commands without typing a password. However, when you do so you will not be authenticated to Kerberos on the remote host, and thus will not be able to access protected AFS space and other services that require authentication.
The examples below show how to do some common tasks using SSH. See the man pages for ssh and scp for additional information and options.
To login to a remote Facilitized Unix host
will log you into the remote host (assuming you have an account on it). You will have to run kinit afterwards if you want access to AFS and other authenticated services.
To run a command on a remote Facilitized Unix host
ssh <remotehost> <command>
ssh ux4.sp.cs.cmu.edu ls
will run the given command on the remote host
To copy files between two hosts
scp <filename> <host>:<filename>
scp myfile.txt gs999.sp.cs.cmu.edu:myfile.txt
will copy "myfile.txt" from the host you typed the command on to your home directory (since no target directory was explicitly specified) on the host gs999.sp.cs.cmu.edu. As with other SSH commands that are run with automatic Kerberos authentication, you will not be authenticated to AFS on the remote host, so copies to protected AFS directories will fail.
Using SSH on Windows hosts
The SSH clients on Windows provide the much of the same functionality as the Unix clients, though they do not support the Kerberized authentication that the SSH clients on Facilitized Unix hosts support. Thus, you will have to type your SCS Kerberos password (or use public key authentication) to login to and run commands on foreign hosts. The exact instructions for using these clients depends on which SSH package you have installed. The examples below use PuTTY. PuTTY has extensive on-line help which can be consulted for advanced features and troubleshooting.
To login to a remote Unix host
- Run the PuTTY application & select the Session category
- Select "SSH" as the protocol
- (Optional) Turn on X11 forwarding under Connection > SSH > Tunnels
- Type in the name of the host you wish to connect to, connect, and then type your SCS Kerberos username & password at the prompts.
To run a command on a remote Unix host
The plink command-line client comes as part of the complete PuTTY distribution. It has a similar syntax to the command-line ssh Unix client. You may wish to add the directory with the PuTTY binaries to your PATH (you can use the "Advanced" tab under the "System" control panel to set environment variables under Windows).
plink <user>@<host> <command>
plink email@example.com ls
will run the given command on the remote host. You will be prompted for your password. plink can also be used to set up SSH tunnels. Type plink -help or see the on-line PuTTY documentation for additional command syntax.
To copy files between two hosts
The pscp command-line client comes as part of the complete PuTTY distribution (there are also some graphical front-ends to PuTTY that are available). It has a similar syntax to the command-line scp Unix client.
pscp <file> <user>@<host>:<target>
pscp myfile.doc firstname.lastname@example.org:myfile.doc
will copy the given file to the remote host. You will be prompted for your password. Type pscp -help or see the on-line PuTTY documentation for additional command syntax.
In addition to being able to login to remote hosts, copy files, and run remote commands securely, you can use SSH to set up a encrypted "tunnel" (also known as "port forwarding") between a specific port on your local machine and a port on a remote host on which you have an account. This is useful in order to have SSH encryption for traffic that would otherwise go over the network in the clear.
ssh -L local_port:remote_host:remote_port forwarding_host
will do the following:
- An SSH connection will be made from the local host (the host you typed the command on) to the forwarding_host.
- If you make a connection to the local_port on your local host, any packets you send on that connection will be sent to the forwarding_host over the SSH connection from step 1.
- The SSH server on the forwarding_host will then forward these packets to the remote_port on the remote_host.
- Any packets from the remote_port on the remote_host will be sent back along the same path.
Some things to note:
- If the forwarding_host and remote_host are the same host, then all data going over the network is encrypted by SSH.
- If the forwarding_host and remote_host are not the same host, then data between the forwarding and remote hosts will not be encrypted by SSH.
- In addition to providing security, one can use SSH tunneling to to bypass some IP-based access restrictions. For example, you can make requests to SCS netnews servers from your off-site machine look like they are coming from your SCS desktop.
As an example of using SSH tunneling to provide security, suppose the user "bovik" wanted to be able to use POP3 to read his mail from his maildrop machine (e.g. ux1.sp.cs.cmu.edu) without worrying about any password information (even his .mail instance password) going over the network in the clear. To do so, could run the following command as root (but with Kerberos tickets for bovik) on his local machine:
ssh -L 110:ux1.sp.cs.cmu.edu:110 -l bovik ux1.sp.cs.cmu.edu
What this command does is to set things up so that if he connects to port 110 on his local machine, any traffic that goes over that connection will be sent via an ecrypted SSH connection to the SSH daemon on ux1. The SSH daemon on UX1 will then send the traffic to port 110 on ux1 and forward any traffic from that connection back to bovik's local machine. The result is that all bovik now need to do is configure his mail reader to use port 110 on localhost as the POP3 server. Note that the above command had to be run as root in order for it to bind to a port less than 1024, and it needed Kerberos tickets for bovik in order to avoid having to manually type a password when connecting. It's also assumed that there is not already a POP3 server running on the local host.
One can also do "remote forwarding", which will bind a port on the remote machine and forward it back to the local machine.
Connecting to non-Facilitized hosts
You can use SSH on Facilitized hosts to connect to non-Faciltized hosts that run sshd. However, there are a few things to be aware of:
- If you've never connected to the remote machine before, you'll get a warning message about the host being unknown. In general, unless you're paranoid, you can just tell ssh to go ahead and connect, and everything will be fine. Since SSH uses a public/private encryption system to negotiate the connection, the remote machine can safely send you it's public encryption key for you to use in connecting to the machine. If you're particularly paranoid you might want to verify that this key is actually the key of the remote machine. It'll be stored in ~/.ssh/known_hosts, and you can compare it against /etc/ssh_host_key.pub on the remote machine.
- If the remote machine isn't using our Kerberos setup, you won't be able to automatically login without setting up public/private keys. To set up these keys, see the man pages for ssh-agent, ssh-keygen, and ssh-add under Unix and the documentation for your particular SSH client under Windows. If you do not set up these keys, you will have to type a password whenever you connect.
The following off-site links will open in a new browser window: