High Performance Computing Environment

P. G. Senapathy Centre for Computing Resources
Login





SSH USAGE



Table of Contents
  • SSH mandatory at HPCE
  • Why
  • How: usage
  • Bonus 1: automatic defining X11 environment in a safe way
  • Bonus 2: no need to type in password
  • Sometimes SSH is too secure...
  • Feedback

SSH mandatory at HPCE
The only way to access HPC systems is by using ssh, scp or sftp.

Why
It is commonly known, that a normal telnet or ftp connection to a remote system can be very unsafe. In many cases it is possible to use a computer to catch all tcp packets that are put on the local network. All data that is send via the local network to a remote (or local) computer system can be read by anyone who has access to a computer that is linked to the local network. This is especially very undesirable in the case of passwords that are sent to other systems. The SSH standard circumvents this problem, by encrypting all data that is sent over the network, also the passwords needed for authentication.

How: installation on your work station
Installation of the software involved is, as far as we experienced, rather simple. The central site for the open SSH is http://www.openssh.com.There one finds implementations for Unix-es, Windows, Macintosh. In the following we will elaborate somewhat on the different platforms:
  • Unix
    On http://www.openssh.com SSH versions for many Unix-es are available. You will also need SSL, to be found on http://www.openssl.org. If unsure, check for the file libssl.a in /usr/local/ssl/lib/ or other "standard" locations. Most, if not all, linux distributions support SSH. Installation from source is easy, one doesn't even need root permission to install the ssh and scp (replacements for telnet and ftp) in one's home directory.
  • Windows
    There are some implementations of SSH for Windows, see http://www.openssh.com/windows.html. We tried PuTTY as a terminal emulator http://www.chiark.greenend.org.uk/~sgtatham/putty/ and it works satisfactorily. For secure filetransfer is WinSCP, with a graphical user interface, a good possibility.
  • Macintosh
    Look at http://www.openssh.com/windows.html for references. We tried MACSSH http://sourceforge.net/projects/macssh/, which works well.

How: usage
  • Logging in on one of HPC systems:
ssh -X myname@hpc-system1
where myname is the login name/userid on the HPC system, and hpc-systeml is the internet address of the HPC system. The -X flag is for the automatic arranging of your X environment. It depends on the configuration of ssh on your local workstation if this flag is necessary.

  • Copying files from your workstation to the HPC system:
    On your workstation type:
scp infile myname@hpc-system1:dir/tofile
Where infile is the file you want to copy (you can specify more than one file and use wildcharts if you like) and directory is the destination directory on the HPC system. When you omit directory, the file(s) will be copied to your home directory. tofile is the name the file gets on the HPC system. When omitted, the name will be the same as infile.

Copying files from the HPC system to your workstation: On your workstation, type:

scp myname@hpc-system1:dir/infile outfile

infile is the name of the file on the HPC system, outfile is the name of the file on your workstation.

Copying directories:
You can copy a directory by specifing the -r flag.


Bonus 1: automatic defining X11 environment in a safe way

There is a famous security problem connected with using X11 applications if your workstation is running some kind of UNIX. Many people used the xhost command to produce X11 output on their screens. Not everbody is aware of the fact, however, that using the xhost command one creates very likely a situation where somebody, also logged in on the remote system can get access to the X-server running on the workstation and is able, for example, to read out every keystroke.

So we cannot stress enough: DON'T USE XHOST.
An alternative and more approved approach is the use of 'cookies' with the 'xauth' command.
Using ssh, neither of xhost or xauth is necessary, as ssh takes care of the X-window traffic, and setting the DISPLAY environment variable. Once you have a ssh connection from your Unix workstation with a HPC system, X-applications will automatically put their windows on your workstation, and all traffic is encrypted. Depending on the configuration of your system, you have to add the -X flag to the ssh command. When using PuTTY under Windows, choose 'Tunnels' from the 'Category' list and check the option 'Enable X11 forwarding'. Please note that you need a separate X-server, e.g. http://www.straightrunning.com/XmingNotes/.

Bonus 2: no need to type in password
Another bonus is the possibility to login without using a password. For details, have a look at http://www.openssh.com, but in its most simple form you could do the following:
On your workstation, issue the command:


ssh-keygen -t rsa

Enter a sentence you can remember easy for the pass-phrase question.

cd to your $HOME/.ssh directory on the workstation and notice, that a file id_rsa.pub is located there. Append this file to the file $HOME/.ssh/authorized_keys on the HPC system. You can log in from your workstation to the HPC system using the pass-phrase.
Now you can arrange that you have to type in the pass-phrase only once per login-session on your workstation: When you are using the GNOME or KDE desktop environment, enter the commandssh-add after which you will be prompted for your pass-phrase. The system remembers your pass-phrase and it is supplied automatically with subsequent ssh and scp commands.
When you are not using KDE or GNOME, it depends on your environment how to proceed. The general principle is, that you must be working in an environment started with ssh-agent, the KDE and GNOME environments take care of that. If you are not running KDE or GNOME, try something like:

ssh-agent bash

and give thessh-add command.
If the directory $HOME/.ssh does not exist on the HPC system, you can create that directory:
mkdir -m 0700 $HOME/.ssh

Sometimes SSH is too secure...
When you make a SSH connection to a remote system for the first time, SSH logs in the file $HOME/.ssh/known_hosts the hostkey of that system and asks if you want to proceed. If you enter yes, the hostkey of the remote system is stored in $HOME/.ssh/known_hosts on your local system. When you make later on again a SSH connection to the same system, SSH compares the hostkey with the stored hostkey. If there is a difference, you will get a warning and some functionality is not available. This is to protect you from possible attacks: you think you are connected to a particular host, but in reality you could be connected to another host (the so called "Man in the middle attack")
Most of the times, however, there is no problem because the hostkey of the host system has been changed for some reason, perhaps by upleveling the system. If you are sure that you are really connecting to the system you want, simply remove the line with the name of the remote host in the file $HOME/.ssh/known_hosts and connect again. You could also try a more drastic approach: remove the file $HOME/.ssh/known_hosts altogether. The above is for Unix systems. In general, the SSH implementations for Windows and Macintosh issue a warning and let you choose to change the stored hostkey.

Feedback

HPCE considers easy and secure access to the HPC systems important, so in case of difficulties, please contact hpce@iitm.ac.in.