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.
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):
|EMSEI Sun Workstations||Yes|
|EMSEI Cray (earth)||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.
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 www.lysator.liu.se/~jonasw/freeware/niftyssh. Unfortunately, it does not support sftp.
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 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.
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:
sftp: command not foundthen the machine you're logged in to probably does not have sftp installed.
[21:07:37] quartzite:~$ sftp stout Connecting to stout... Protocol major versions differ: 2 vs. 1 Couldn't read packet: Bad file descriptorThat 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 descriptorthen 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).
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.
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 (184.108.40.206)' 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,220.127.116.11' (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:
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.
This is helpful when you're going between different unix accounts with different usernames.
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.
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:
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.
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.
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.pubThe 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.
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_keys2alpha'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.
beta% chmod 600 authorized_keys2 beta% ls -l authorized_keys -rw------- 1 woods woods 662 Feb 8 18:04 .ssh/authorized_keys2The 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.
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:
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.
now the password prompt looks like:
Enter passphrase for RSA key 'user@hostname':
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEArzsEoZm8chAsLf0R8yG3FUOCTB1JinJ0P8RPjGDd3B1x dPC4JVGntIA7rsEQj5Aw1n1CylYJiDt4UnBKMg9h56irkI8U/EGJTlHfkoU9ZbAZgbWmG4YzRDJyp79J 4wYjNmXJp27vGJPeSuM/o/XK5lRO5bxGWZ+u2IO7BZ3Odx8= woods@graniteThe 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