Our UNIX systems, including our clusters, require the use of the Secure Shell Protocol (SSH) protocol in order to login. SSH provides a terminal interface so that you can type commands, and interact with the computer, although with additional software and setup you can also run UNIX graphical programs. SSH is intended to provide secure connections, so that you can be sure that it is safe to provide your password, and also so that you can be sure that no one is able to intercept your network traffic and spy on you.
Mostly you should be able to just use SSH without worrying too much about the encryption details. However, you do need to be aware of some issues that might arise when you first connect to the remote system. Each SSH server (the software running on the remote computer) will generate a unique host encryption key which it then uses with your client to transfer a key which will be used for that particular log in session. Until that session key is in place you are vulnerable to a so-called "Man in the Middle Attack" in which an attacker intercepts your packets, and sends them to the remote system. When the remote system responds, the attacker system will take the response, and send it back to your computer. During this time it is able to make copies of the network traffic, and reconstruct the conversation. You would not be aware of this, and SSH will not be able to detect that this has occurred. For this reason, SSH will record the host key for a given system. If the host key changes for some reason, you'll be warned about this and you should not continue logging in without contacting us to see why the key may have changed. Additionally the first time you log in to a system, you will be asked that the host key presented by the server is the actual key for the server. For the maximum amount of security you should confirm that the correct key has been presented, and for this reason the keys of CCBB maintained servers are listed below.
* ceres:
openssh md5: 6b:68:2b:d1:58:e2:ed:8a:5a:d1:35:f7:71:bf:79:76
bubblebabble: xihom-gunag-zuzar-myzor-fifem-myzut-ryper-zinab-humec-gomen-taxyx
* chencluster:
openssh md5: 98:b8:7b:5c:80:93:60:97:47:6f:08:75:9b:b1:8c:4c
bubblebabble: xocor-byrik-kurup-ronub-migom-vamar-cidim-firav-tysef-copyt-suxux
* dacha:
openssh md5: 4e:08:9a:de:2f:ab:17:8a:41:73:cd:fb:64:41:2f:cd
bubblebabble: xocig-cazan-tevab-zalys-dopan-kynef-zobon-syfas-kevad-vysor-haxyx
* files:
openssh md5: 1a:86:e8:12:a8:65:0f:2d:eb:b7:eb:ca:40:f9:e7:d5
bubblebabble: xetic-bodep-kupen-pesak-kobik-vacym-dypiz-vusyn-nysab-buted-rexux
* genomes:
openssh md5: 55:2d:23:28:9d:36:b7:61:d2:31:9c:87:a9:48:73:b0
bubblebabble: ximet-susah-mabub-delik-dudyh-lufyg-semaz-zetys-migyg-dydam-vuxax
* kremlin:
openssh md5: 22:b3:8a:76:70:39:de:7d:0a:d6:fb:d6:02:da:4f:69
bubblebabble: xemaf-fecup-tideb-pyzum-gipel-vacad-veles-popar-dimab-kihah-loxox
* phylocluster/phylocluster2:
openssh md5: c8:b5:47:81:ff:96:2c:65:a3:0b:26:ca:78:7b:3a:3e
bubblebabble: xezom-nobop-suzol-kolin-gafut-hyges-murak-datav-hyzil-zobid-puxox
openssh md5: 3d:b4:b6:25:a7:fd:8d:78:2b:52:d6:00:76:35:2a:cd
bubblebabble: xobem-rabob-zyvaf-tymuk-gomum-dideg-ziluf-hunum-lopov-mybik-nixyx
openssh md5: 4e:08:9a:de:2f:ab:17:8a:41:73:cd:fb:64:41:2f:cd
bubbblebabble: xocig-cazan-tevab-zalys-dopan-kynef-zobon-syfas-kevad-vysor-haxyx
Clients
To use SSH, you will need to obtain a client. If you use MacOS X, you can open up the Terminal application which is in the utilities folder. You can then use the ssh command to access one of the systems above. Linux users can also go this route. There are also GUI ssh clients. For example, many PC users like the Putty program, and many Mac users like the JellyfiSSH. Both are available from Bevoware (see our software page). To transfer files onto the file server you will need a Secure File Transfer Program (SFTP) (or you can use Windows file sharing from within the building; see the file server docs for more information. MacOS X and Linux terminal users can use the sftp command to do this. WinSCP is a good PC client, and FUGU is a good Windows client.
Using Keys for Logins
Besides host keys, ssh allows users to use keys to negotiate a login. This has the benefit of not requiring you to send a password to the server, which in turn prevents it from being exposed if the server has been compromised. To use a key start by creating it
ssh-keygen -b 1024 -f ~/.ssh/ccbb -t dsa
For now when you are asked to type the passphrase to protect the password, please do so. This is actually another benefit of a key based login, because passwords usually have size limits where a passphrase can be something like "i can haz cheezeburger" – something memorable, yet long enough to not be easily guessed.
This creates two files called ~/.ssh/ccbb and ~/.ssh/ccbb. These should be protected by running
chmod 400 ~/.ssh/ccbb*
These ensures that only the owner can read the files, although with the pub version of the file you are just to prevent yourself from overwriting. The pub file contains the public key which can be posted on your web page, put into an email, or whatever else you want to do with it. At least, copy it over to the remote server where it should be stored in ~/.ssh. Then log in, and run
cat ccbb.pub >> authorized_keys
BE SURE THAT YOU USE >> OR ELSE YOU WILL OVERWRITE authorized_keys. Once the key is stored you can can remove ccbb.pub.
Now you are ready to log in. The command line way to do this is
ssh -i ~/.ssh/foo host.ccbb.utexas.edu
You should be asked for your passphrase, and if you correctly type it in you should be allowed access. If you use a ssh config file, then you can add a entry IdentityFile which lists out the identity file.
Hands-Free Logins
The other benefit of using keys for logins is to have logins which don't require you authenticate. This is useful when repeatedly uploading files, or logging in repeatedly. The obvious way to do this is to just hit return when you are asked to provide the passphrase protecting your key. You do this the first time you log in to the cluster, because the batch queuing software, SGE, uses ssh to log into compute nodes. This is done on your behalf by SGE, and you won't have an opportunity to provide a passphrase. If you protected that key with a passphrase, job submissions will fail. This same problem will happen with job scripts that use scp to transfer files. Those scripts will need to use ssh with a key that is not protected by a passphrase.
In all other cases, you want to have a protected key. Otherwise, anyone that has access to your account, and use your key to compromise other systems. Luckily ssh provides a useful utility called the SSH agent. When using a terminal based version of ssh (eg, Linux terminal, cygwin on PCs, or Mac's Terminal.app) type
eval `ssh-agent`
Note that these are the backquote (`) and not the regular quote ('). The eval is a bit of shell magic to make sure that the agent is available to any scrips or programs that run. For example, if you have started the agent, and then you run a script which scp's some data, then scp running in the script will be able to use the agent. Once the agent is running
ssh-add ~/.ssh/ccbb
and provide your passphrase. Now when you log in to the remote server the agent will be consulted for keys which have been unlocked, and if one of these keys accepted by the server.
Of course, this means you should lock your screen when you leave your computer. Might also use the -x option with ssh-add to lock the agent when you are not using; the -X option unlocks the agent. Read the ssh-add man page for more info. If you are done with the agent, simply close the terminal you started it in. You can also run
ssh-agent -k
to kill the agent. Finally, if you are using a windowing system such as KDE or GNOME in Linux, it is possible to have 1 agent that is started when you first log in, but this setup is advanced, and should be researched online.
