Secure interhost communcation - SSH

SSH (the Secure Shell client) enables a user to login to a remote machine and execute commands there. It provides secure encrypted communication between two untrusted hosts over an insecure network and replaces rlogin and rsh. SSH network tools provide secure alternatives to telnet, rlogin, rsh, rcp, and related Unix programs. Versions for for Windows and Macintosh platforms are also available.

SSH allows you, for example, to 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 transactions, between hosts through SSH tunneling.

How to get SSH

[The offsite links below will open in new browser windows.]

For Unix: Facilitized Unix hosts have, by default, a version of SSH that understands Kerberos. If you are using a non-Facilitized Unix host, you can get SSH from http://www.openssh.com or download precompiled 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 simple, 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 it 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

The command:

ssh <remotehost>

for example:

ssh linux.gp.cs.cmu.edu

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

The command:

ssh <remotehost><command>

for example:

ssh linux.gp.cs.cmu.edu ls

will run the given command on the remote host

To copy files between two hosts

The command:

scp <filename><host>:<filename>

for example:

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, which has extensive online help 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).

The command:

plink <user>@<host><command>

for example:

plink bovik@linux.gp.cs.cmu.edu 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 online 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.

The command:

pscp <file><user>@<host>:<target>

for example:

pscp myfile.doc bovik@linux.gp.cs.cmu.edu:myfile.doc

will copy the given file to the remote host. You will be prompted for your password. Type pscp -help or see the online PuTTY documentation for additional command syntax.

You can also use SSH to set up a encrypted "tunnel" (also known as "port forwarding") between a specific port on your local machine and one on a remote host on which you have an account. This mechanism is useful in order to have SSH encryption for traffic that would otherwise traverse the network in the clear.

The command:

ssh -L local_port:remote_host:remote_port forwarding_host

will do the following:

Open an SSH connection from the local host (the host on which you typed the command) 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 offsite machine look like they are coming from your SCS desktop.

As an example of using SSH tunneling to provide security, suppose Harry Bovik (user "bovik") wants to read his mail from his maildrop machine (e.g. linux.gp.cs.cmu.edu) using POP3, without worrying about any information (even his .mail instance password) going over the network in the clear. To accomplish this goal, he could run the following command as root (having already obtained Kerberos tickets for "bovik") on his local machine:

ssh -L 110:linux.gp.cs.cmu.edu:110 -l bovik linux.gp.cs.cmu.edu

This command sets things up so that when Harry connects to port 110 on his local machine, any traffic over that connection will be sent via an encrypted SSH connection to the SSH daemon on Linux.gp. The Linux.gp daemon will then forward the traffic to port 110 on the same machine and any return traffic from that connection back to Harry's local machine. The result is that all Harry 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 Harry's Kerberos tickets in order to avoid having to type a password manually when connecting. This example also assumes that no POP3 server is already running on the local host.

One can also do "remote forwarding," which binds a port on the remote machine and forwards 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.