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.
Note that, this is the only way you will be able to start a remote session on one of our departmental workstations. Remote sessions from outside the EMS network to the department linux workstations can only be initiated via ssh or sftp into the following nodes unless you use the college VPN software:
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
(http://www.psu.edu/dept/cac/internet/ssh/index.html) about SSH on their site as well.
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.
Its use is very similar to traditional FTP. Please sftp rather than traditional ftp whenever possible to avoid sending your password in clear text.
and SFTP Clients
Here are some SSH clients that we recommend for connecting to remote machines:
NiftyTelnet-SSH is a free version 1 SSH client for the Macintosh. It is available from
http://www.lysator.liu.se/~jonasw/freeware/niftyssh. Unfortunately, it does not support sftp.
Penn State has
a site license for MacSFTP for OS X. You may download it from https://downloadits.cac.psu.edu/.
You will need a valid Penn State access account in order to download
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.
Ssh is already installed on all PSU Meteorology Linux machines. 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.
If you support your own linux/unix machine, OpenSSH is a free SSH implementation that's available from http://www.openssh.com. Wherever possible, this is the ssh implementation that we use on the Linux machines.
Troubleshooting and Messages
Some of SSH's messages can be somewhat cryptic. Here are some tips to help explain some of them.
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).
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
lethe:pavloski : sftp stokes
Connecting to stokes..
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:
lethe:pavloski : sftp localhostthen 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).
Connecting to localhost...
Request for subsystem 'sftp' failed on channel 0
Couldn't read packet: Bad file descriptor
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]
stokes:~> ssh lethe
The authenticity of host 'lethe (18.104.22.168)' can't be established.
RSA1 key fingerprint is
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 'lethe,22.214.171.124' (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.
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.
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 linux command-line client, you can specify alternate userids using the following syntax:
This is helpful when you're going between different linux 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.
The basic steps are:
1. Use ssh-keygen
to create a passwordless set of identity keys.
2. Add the public key to the ~/.ssh/authorized_keys2 file on the remote host.
3. 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 PSU Meteorology 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 support (firstname.lastname@example.org) and we can help you find a convenient, secure solution.
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/meteo/pavloski/.ssh/id*
-rw------- 1 pavloski users 530 Feb 8 18:13 /home/meteo/pavloski/.ssh/id_rsa
-rw-rw-r-- 1 pavloski users 334 Feb 8 18:13 /home/meteo/pavloski/.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:pavloski: chmod 600 authorized_keys2
beta:pavloski: ls -l authorized_keys
-rw------- 1 pavloski users 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:
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.
After following the directions ssh still asks for a password, although where the prompt used to be:
now the password prompt looks like:
Enter passphrase for RSA key 'user@hostname':
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.
After following the directions, ssh still prompts for a password in exactly the same way.
- 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
The private key is much larger, spans multiple lines, and has tags at the beginning and end that identify it as the private key.
(Rev. CFP 21-Mar-06, shamelessly stolen from Scott Woods)