Secure Shell (ssh)

"ssh" and "secure shell" are registered trademarks of SSH Communications Security Corp.

To use secure shell to connect to the National Facility machines, you will need to have the secure shell software installed on your local hardware as well. There are various clients around. We have experience with SSH1, SSH2 and OpenSSH on unix platforms. You may also be interested in Nifty Telnet SSH for Macintosh and Putty for Windows. To transfer files between Windows computers and the National Facility machines using SSH you can use Filezilla by specifying sftp://sc.apac.edu.au or sftp://lc.apac.edu.au as the address. For a full XWindows emulator on your PC or Mac, VNC is recommended.

For an excellent FAQ on secure shell, including more details on where to get it, and how to install and run it, see http://www.employees.org/~satch/ssh/faq/

There are two versions of ssh, ssh1 and ssh2.

They are different protocols and they are not compatible. SSH2 is more secure. The National Facility machines will accept connections from both ssh1 and ssh2 clients. If you are using unix and only ssh1 is installed on your machine then the commands "ssh" and "scp" will mean ssh1 and scp1. If both ssh1 and ssh2 are installed "ssh" and "scp" will mean ssh2 and scp2, and ssh1 and scp1 will be available as separate commands.

Using ssh1 and scp1 without passwords

  1. On any machine (host) run "ssh-keygen" once (it can take a while). Just hit return when it prompts for a passphrase, and again the second time. This will create identity and identity.pub in .ssh/ on that host.

  2. Append the contents of identity.pub into the file .ssh/authorized_keys on any OTHER host you want to talk to with ssh and vice versa. The keys are long so make sure they are still one line after you've copied them if you use cut and paste.

    The same .ssh/authorized_keys file can be used on all machines - i.e. it doesn't matter that the identity.pub of a host is in its own authorized_keys file.

  3. The first time you use ssh between hosts, do so interactively (in both directions!), and answer "yes" to the prompt:

    Host key not found from the list of known hosts. Are you sure you want to continue connecting (yes/no)?

    This will automatically update the known_hosts file with the necessary key to enable non-interactive scp or ssh for future connections.

  4. Remember to use "scp -c none" for data files so there is no encryption.

This is (like) what's in .ssh/identity.pub for ttt900 on host wyrd 

1024 33 147052966448114472101(...3_lines_of_numbers...)30734481163 ttt900@wyrd
ttt900 appends this key into .ssh/authorized_keys on vpp and also the converse (append vpp:.ssh/identity.pub into wyrd:.ssh/authorized_keys). This is what is required to allow ssh and scp commands betwen these two hosts without needing to enter passwords.

Your authorized_keys files on each host will end up with a whole lot of other host keys.

Using ssh2 and scp2 without passwords

An example of setting up a unix computer to access sc.apac.edu.au using ssh2 without a password (change "midge" to the name of your computer):
Get ssh2 from, for example mirror.aarnet.edu.au/pub/ssh/ssh-3.2.0.tar.gz
(ssh-3.2.0 is a version of ssh2)
On your computer
tar -zxf ssh-3.2.0.tar.gz
cd ssh-3.2.0
./configure
make
su
make install
exit
ssh-keygen (or for 3.2, ssh-keygen -t dsa)
(don't use a pass phrase)
substitute your machine name in the next line. (for 3.2 it the directory is .ssh) :
scp ~/.ssh2/id_dsa_2048_a.pub sc.apac.edu.au:.ssh2/yourhost_dsa_2048_a.pub
add this line to ~/.ssh2/identification
idkey id_dsa_2048_a
on sc.apac.edu.au add this line to ~/.ssh2/authorization
key midge_dsa_2048_a.pub
/usr/local/bin/ssh sc.apac.edu.au

What to do if your interactive graphics are too slow

If you are using an interactive graphical program (for example matlab or gambit) and it is too slow, it may be because of the overhead from sending the X graphics through ssh. There are two ways to set up your display for this, depending on how strong you would like the authentication of the display. This will only work for logins to sc0 and sc1. It won't work with the qsub -I "interactive queue" jobs. These require the graphics display to be set by ssh.

For purely interactive jobs on sc0 and sc1 you set your display by typing the following on the sc
tcsh: setenv DISPLAY the-full-name-of-your-desktop-computer:0
bash: export DISPLAY the-full-name-of-your-desktop-computer:0
You can then use either host based, or magic cookies to authorise access to your local desktop.

Method 1: host-based
On your local machine type
xhost +sc.apac.edu.au
This will allow any user on the sc to access your desktop screen.

Method 2: magic-cookies
Before you start the graphical program, copy your authority file from your local machine to the SC.
scp .Xauthority sc_userid@sc.apac.edu.au:temp-xauth
then on sc
xauth merge temp-xauth
This copies a "magic cookie" from your desktop computer to sc so that when sc tries to connect to your display your desktop computer knows that it is allowed to. It will only allow authorised keys (ie ones you have given the cookie to) to attach, rather than the whole machine as in the host based method.