What is SSH?

The Secure Shell protocol (SSH) provides a means for connecting to remote machines via an encrypted network channel. Network packets between the local and remote machines are encrypted to prevent people from eavesdropping on your session; this prevents sensitive information, such as your password, from being intercepted.

Ssh also provides a number of other benefits over telnet or rlogin besides security. For example, when you log into a remote machine using ssh, it will automatically set your $DISPLAY environment variable and xauth authorization so that you can display X applications back to your local host without any intermediate steps.

The Center for Academic Computing has some additional information about SSH on their site as well.

SFTP

Some ssh implementations support sftp, which allows you to securely transfer your files in a way that resembles traditional ftp, except it uses strong encryption so that your password and data aren't sent in clear text.

Unfortunately, sftp is not widely implemented yet, and is only available between clients and servers that both support version 2 of the SSH protocol. You can check your ssh installation's version by running the command "ssh -V" (capital "V"). If it replies with a version number that starts with 1.x, then there won't be any support for sftp. Here's a chart of where sftp is supported (remember that both sides of the connection must support sftp):

Location	Supports SFTP?
EMSEI Sun Workstations	Yes
EMSEI Cray (earth)	Yes
EMSEI SP	Yes
EMSEI Linux machines	Soon

Commercial Windows client listed below	Client only
Macintosh client listed below	No
OpenSSH distribution listed below	Yes, server disabled by default

Its use is very similar to traditional FTP. Please sftp rather than traditional ftp whenever possible to avoid sending your password in clear text.

See the tips below for advice on troubleshooting sftp sessions.

Clients

Here are some SSH clients that we recommend for connecting to remote machines:

Macintosh

NiftyTelnet-SSH is a free version 1 SSH client for the Macintosh. It is available from www.lysator.liu.se/~jonasw/freeware/niftyssh. Unfortunately, it does not support sftp.

Windows

Penn state has obtained a site license from SSH, Inc. The fully licensed Windows client is available from https://www.work.psu.edu/access/ssh/. You will need a valid Penn State access account in order to download the client.

Unix

ssh is already installed on all ECF unix machines. Please use it instead of rlogin, rsh, or telnet. It will encrypt your passwords and data, and will automatically set xauth permissions and your $DISPLAY environment variable so that X applications can be displayed easily. Sftp is availble on the EMSEI Suns, SP and Cray.

If you support your own linux/unix machine, OpenSSH is a free SSH implementation that's available from www.openssh.com. Wherever possible, this is the ssh implementation that we use on the unix machines at EMSEI.

Troubleshooting and Messages

Some of SSH's messages can be somewhat cryptic. Here are some tips to help explain some of them.

Background

A lot of the messages you'll see deal with the difference between the two major protocols of ssh; SSH1 and SSH2. Up until recently, all of the EMSEI machines were running SSH1 tools. Now all EMSEI machines are running SSH2.

SSH1 is the older of the two protocols, and is slightly less secure. It does not support sftp in either direction. SSH2 is generally considered to be more superior than SSH1 in that it offers better security and supports sftp. It's acceptance was limited though, since a truly free implementation was not available until recently (in the form of OpenSSH).

Sftp messages

If you're having trouble starting an sftp session between two hosts, make sure they both support sftp; it's not supported on all implementations or installations:

The local machine:If you can start the sftp command, then the local machine supports sftp; this program is all that's required on the local end. If you get a message like:
```
sftp: command not found
```
then the machine you're logged in to probably does not have sftp installed.
The remote machine:If you try to sftp to a host and get something like the following:
```
[21:07:37] quartzite:~$ sftp stout
Connecting to stout...
Protocol major versions differ: 2 vs. 1
Couldn't read packet: Bad file descriptor
```
That means the remote host is only running SSH version 1, which doesn't support sftp. If you get a message like the following:
```
[21:12:22] quartzite:~$ sftp localhost
Connecting to localhost...
woods@localhost's password: 
Request for subsystem 'sftp' failed on channel 0
Couldn't read packet: Bad file descriptor
```
then the remote host is running SSH version 2, but they don't have the sftp server enabled (OpenSSH ships its sftp server disabled by default).

Sftp under Windows

By default, the windows sftp client will limit you to regular files in your home directory. You can get access to files outside your home directory by checking the box marked "show root filesystem" in the settings under the category "File Transfer". Similarly, it will show files that start with "." if you check the "show hidden files" box in the same window. These changes will take effect the next time you make a connection to a remote host.

"Known hosts" messages

You will receive a message like the following the first time you connect to a new host using ssh:

[05 Apr 22:14] granite:~> ssh stout
The authenticity of host 'stout (128.118.64.231)' can't be established.
RSA1 key fingerprint is 0a:5d:5a:a8:0b:a0:a2:ee:84:87:0d:14:b9:d4:ed:71.
Are you sure you want to continue connecting (yes/no)?

This isn't an error; what's happening is that ssh needs to exchange keys with the remote host, but since it's the first time you've ever connected to that host, it can't verify its identity for you. After you answer "yes" (note that just "y" isn't sufficient, it wants you to type out "yes"), it will save that host's public key in your ~/.ssh/known_hosts2 file, and it won't have to ask you next time you connect to the same host.

It's a similar situation if you receive a message like:

Warning: Permanently added 'galaxy,128.118.52.22' (RSA) to the list of known hosts.

except that SSH was able to verify the machine's authenticity through some other means, so it didn't need to ask your permission.

"Man-in-the-middle" messages

You will get this message if the remote host has changed its host key, either by creating a new one, or by upgrading from SSH1 to SSH2. Basically, the key offered by the remote host differes from the one that SSH saved in your ~/.ssh/known_hosts file the first time you connected to that host.

In either case, you should check with the system administrator of the remote machine to make sure that this is expected. Otherwise, this could represent an attempt to exploit one of the weaknesses of the SSH protocol.

If you know that the remote host has simply been reinstalled or upgraded, you can prevent these messages from occuring by removing that host's key from your known_hosts file so that SSH can collect the new one next time you connect:

On unix: Edit your ~/.ssh/known_hosts and ~/.ssh/known_hosts2 files and delete the lines for that host only. If the messages persist, the system-wide /etc/ssh_known_hosts file may need to be updated as well by the system administrator for your machine.
On Windows: On the commercial SSH windows client, open the settings window and find the selection for host keys. You should be able to select the offending host's key(s) and delete them.

"SSH1 protocol" messages

Some SSH2 clients will always warn you if you're connecting to an SSH1 server. This is just to make you aware that you're not getting the full security benefits of your SSH2 client, since it has to step down to the SSH1 protocol. Some of these clients have an option under "settings -> security" to suppress this message, others do not, and you'll simply have to click or type yes each time to acknowledge the message.

Other Tips

ssh supports several encryption schemes, some of which are more efficient than others. If you're transferring a large amount of data from outside the ECF, or you're having trouble with connection speeds, you may want to try setting the encryption algorithm to "blowfish", which is superior in speed and security to the default algorithm. This can be specified using the "-c" option to the unix ssh/scp commands, e.g. "-c blowfish". All ECF machines are set to request blowfish by default when you run the various ssh commands.

With the unix command-line client, you can specify alternate userids using the following syntax:

ssh username@hostname.essc.psu.edu

This is helpful when you're going between different unix accounts with different usernames.

When you're using scp to transfer multiple files, you can use a "*" if you surround it in single quotes (so that it doesn't get expanded by the shell on the local machine):

scp 'remotehost:mydir/*' .

note that since I didn't put a "/" before "mydir", scp will assume it should look for "mydir" in my home directory on the remote host.

SSH Without Passwords

In some situations, it's useful to be able to run a command or script on a remote host without having to supply a password, such as from a cron job. Ordinarily, ssh prompts for your login password and uses this to authenticate you to the remote host, but there is a way to get an ssh server to accept commands from a specific known client without having to provide a password using a method called RSA authentication.

This will also work for transferring files using the scp command, but unless the data is too sensitive to make publicly available, putting it in your anoymous FTP directory is easier, safer, and faster.

The basic steps are:

Use ssh-keygen to create a passwordless set of identity keys.
Add the public key to the ~/.ssh/authorized_keys2 file on the remote host.
Verify that the authorized_keys2 file has 600 permissions.

Note: Please be very conservative in your use of this technique. In particular, do not use it to access ECF machines from a different network. While the security provided by ssh is considerably better than that provided by rsh, you will be creating an open conduit from the remote network to this one; if your account is compromised on the remote machine, the attacker will have free reign on our network as well! Do not apply this technique out of laziness. If you have a problem trying to perform tasks across different sites, please contact us and we can help you find a convenient, secure solution.

Example

Let's say you want to run a remote command on the machine "beta" from the machine "alpha" without supplying a password. Instead of authenticating using a password, you can use the command ssh-keygen to create a pair of public and private keys that can be used for authentication.

The first step is to create a set of public and private keys that uniquely identify your userid on "alpha". Log into alpha and run the command:
alpha% ssh-keygen -t rsa -N ''
(This command can take a long time to run on some machines). When it asks you what file you would like to save your key as, you can just press return, to accept the default location. This will create two files on alpha:
```
alpha% ls -l /home/woods/.ssh/id*
-rw-------   1 woods    woods         530 Feb  8 18:13 /home/woods/.ssh/id_rsa
-rw-rw-r--   1 woods    woods         334 Feb  8 18:13 /home/woods/.ssh/id_rsa.pub
```
The id_rsa file contains the private key (note that it is not world or group readable) that represents your identity on that particular machine. The private key should never be transferred from the machine or have its modes changed. The id_rsa.pub file is the public key, which is world-readable. ssh and other programs can use this key to encrypt messages that only you can decrypt using the private key.
The -N '' argument to ssh-keygen specifies that there should be no password associated with these keys. Keys can have passwords just like accounts, but that would defeat the purpose here.
The next step is give alpha's public key to beta, and tell beta that alpha is authorized to run remote commands using RSA authentication.
You do this by copying the contents of alpha's id_rsa.pub (not id_rsa!) to a file called authorized_keys2 in your .ssh directory on beta:
```
beta% cd ~/.ssh
beta% ssh alpha 'cat .ssh/id_rsa.pub' >> authorized_keys2
```
alpha's public key is now in the authorized_keys2 file on beta, telling beta that alpha is authorized to use RSA authentication to log in.
By the way, it's fine to have more than one key in the authorized_keys2 file, in case you need more than one host to be able to do RSA authentication to beta.
The last step is to make sure the authorized_keys2 file on beta has modes 600. This ensures that no one else can view this file.
```
beta% chmod 600 authorized_keys2
beta% ls -l authorized_keys 
-rw-------   1 woods    woods         662 Feb  8 18:04 .ssh/authorized_keys2
```
The first command removes all of the bits for "group" and "world" permissions, making sure that you're the only one who can read and write to this file. The second command verifies that it was successful.

You can now ssh from alpha to beta without using a password.

Differences with SSH1

Note that this is the technique used when both clients support the newer SSH2 protocol. If either host only supports the SSH1 protocol, the instructions are slightly different:

The indentity keys are called identity and identity.pub
You don't supply the "-t rsa" option to ssh-keygen
The authorized_keys2 file should simply be called authorized_keys
The 600 modes on the authorized_keys file is required, not just suggested

Troubleshooting RSA authentication

When troubleshooting ssh in general, it can be helpful to add the "-v" argument to ssh or scp. This will give you lots of information as to what ssh is doing, and how you are being authenticated.

Problem:

After following the directions ssh still asks for a password, although where the prompt used to be:

user@hostname's password:

now the password prompt looks like:

Enter passphrase for RSA key 'user@hostname':

Suggestion:

The prompt is different because It's no longer asking for your login password for the remote host, it's actually asking for the passphrase used to encrypt your identity keys. You probably forgot the -N '' arguments to ssh-keygen, which tells it to generate keys with null passwords.

Problem:

After following the directions, ssh still prompts for a password in exactly the same way.

Suggestions:

Add the "-v" option to ssh, to see how you're being authenticated to the remote host.
Make sure the modes for .ssh/authorized_keys2 on the remote host are set to 600, which looks like -rw------- when you do a long listing (ls -l).
Make sure you copied the public key id_rsa.pub to the remote host's .ssh/authorized_keys2, and not id_rsa (which would be the private key). The public key should be one long line of text (make sure no carriage returns crept in there when you copied it), and should look something like:
```
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEArzsEoZm8chAsLf0R8yG3FUOCTB1JinJ0P8RPjGDd3B1x
dPC4JVGntIA7rsEQj5Aw1n1CylYJiDt4UnBKMg9h56irkI8U/EGJTlHfkoU9ZbAZgbWmG4YzRDJyp79J
4wYjNmXJp27vGJPeSuM/o/XK5lRO5bxGWZ+u2IO7BZ3Odx8= woods@granite
```
The private key is much larger, spans multiple lines, and has tags at the beginning and end that identify it as the private key.

Back to the index