Login and data transfer

Article written by Irene Reichl (VSC Team) (last update 2024-07-04 by grokyta).

Let us have a look at the first part, in the figure above you can see how the connection from the local machine to the remote VSC login nodes work.

In order to be able to login VSC you need

• a user account
• project leader (re-)sets
  • username
  • password
• phone number for receiving OTP (One Time Password)
• to be inside university network either:
  • physically
  • or via VPN-connection to your university
• a terminal program, e.g. xterm (LINUX), terminal (OSX), putty (originally designed for the Windows platform, however, can also be used on other platforms: https://www.putty.org).

alternative to standard terminal ssh connection putty

vscX stands for the vsc you wish to connect with

As stated before, putty was originally designed for the Windows platform, however, can also be used on other platforms, you can download it from: https://www.putty.org)

Login via

# <me> represents your username
# VSX represents the cluster you wish to log in
[...]$ ssh <me>@vscX.vsc.ac.at

assigns you to a clusters login node per round robin manner.

In PuTTY you first configure the connection like in the image at the top, and when connecting, you only need to type the username and not the server address too.

VSC-4 has 10 named l40, …, l49.

VSC-5 has 10 named l50, …, l59.

You may have reason to login to a specific login server:

# ln is a placeholder for the actual node e.g. l43
[...]$ ssh <me>@ln.vsc.ac.at

This may be necessary for trouble shooting.

With the .bashrc file in your home directory you are able to set your preferences for your bash shell. On VSC we provide a recommended .bashrc file that you may use if you like.

For some libraries on VSC it is important that you have set the language settings properly. A locale is a set of environmental variables that defines the character encoding, language, time/date format, numbers, … for your system libraries and locale-aware applications on a Linux system.

Maybe in your local

/etc/ssh/ssh_config

you find a command

SendEnv LANG LC_*

which means that in ssh connections the local environment is taken to the remote machine. E.g., my local settings are, where some variables are not set as you see.

LANG=""
LC_CTYPE="UTF-8"
LC_ALL=

That is one point. But even if you do not take your local language settings with you,

has no value on VSC, by default.

Way out: For certain libraries it is necessary to set these two lines in your .bashrc:

# .bashrc
``` {.bash}
export LC_CTYPE=en_US.UTF-8
export LC_ALL=en_US.UTF-8

With the way we logged in so far one problem rises, the need to enter your Password even though the OTP holds for 12h.

Share the Key with the Cluster

Using ssh-keys is a possible which enables to open several shells on the cluster by using a passphrase only once.

Therefore you generate a key on your local machine which you copy to the remote machine. In order to login you use port 27 instead of the default ssh port 22. The key -optimally and we really ask you to generate it that way- is protected by a passphrase. This passphrase should be as secure as possible.

WIKI-link: ssh-keys

You may want to jump (tunnel) over a host which is between your local machine and VSC. Then you need to copy your key to both machines, the jump host and VSC.

[...]$ eval `ssh-agent`     # start ssh agent
[...]$ echo $SSH_AGENT_SOCK # check if it is running
[...]$ chmod 700 ~/.ssh     # change rights of .ssh-directioy
[...]$ ssh-keygen -t rsa    # generate key on local machine

will be asked to create a pass phrase. that passphrase must be as secure as your password.

IT IS POSSIBLE AT THAT POINT TO GIVE NO PASSWORD, BUT NEVER EVER GENERATE A KEY WHICH IS NOT PROTECTED !!!

This may be a hazard for our system.

[...]$ ssh-copy-id <me>@vscX.vsc.ac.at # copy key to remote machine

will be asked for password & OTP

more about the ssh agent

If you copy with scp you always copy everything. On one hand, it may take ages until everything is copied, on the other hand, you may waste storage if there had only been minor modifications in your data. For that reason you may use rsync which first compares source and destination directory/file structure, subsequently only copying what did actually change. This saves time and disc space.

scp <source> <destination>
scp <me>@vscX.vsc.ac.at:~/<myfile.c> .
scp myfile.c <me>@vscX.vsc.ac.at:~/

rsync [OPTIONs] <source folder> <destination:folder>
maybe useful: -av, --exclude=/daten/temp/...

in order to setup on the remote machine, follow: Backup

For using FileZilla, make sure that you choose “interactive login”. This is necessary to be able to login via two factor authentication. If you are already logged into the cluster via, e.g., PuTTY or another terminal program, you can also login via a normal session because the OTP is only asked once in 12h per cluster and IP address.