Since November 2013, access to VSC has been restricted to IP addresses associated with participating partner universities of the VSC project. Users wishing to connect from outside these IP ranges must first log in to a machine or service within their university network.

Common methods for connecting include using a Virtual Private Network (VPN) or an SSH gateway provided by the university.

For further guidance, refer to Login and Data Transfer and Connecting from Windows.

• University of Vienna: English | German
• TU Vienna: English | German
• University of Innsbruck: German
• University of Graz: German
• TU Graz: Web Single Sign-On

Users may initially connect to any Linux machine within their university network and then access VSC. Some universities offer a dedicated SSH gateway. (If you are unsure how to connect, please contact your local IT services.)

user@host:~$ ls -dl ~/.ssh
drwx------ 4 user user 4096 Dec  6 09:20 /home/user/.ssh

Ensure this directory is accessible only to your user. If permissions differ from the example above, adjust them with:

user@host:~$ chmod 700 ~/.ssh

Your SSH passphrase should be as robust as your password. Generate your key with:

user@host:~$ ssh-keygen -t rsa

By default, the private and public keys are stored in your `$HOME/.ssh` directory. The `id_rsa` file is the private key and should be kept secure and confidential. The `id_rsa.pub` file is the public key used for authentication on remote machines. Verify the permissions of these files to ensure they are correct. They should appear as follows:

user@host:~$ ls -la ~/.ssh/id_*
-rw------- 1 user user 1766 Dec  6 09:15 /home/user/.ssh/id_rsa
-rw-r--r-- 1 user user  394 Dec  6 09:15 /home/user/.ssh/id_rsa.pub

For more details, see sshkeygen.

To log in with your key on a remote machine, you must add the contents of your `id_rsa.pub` file to the `authorized_keys` file in the `.ssh` directory of the remote machine. Log in to the remote machine and use a text editor to append your public key. Verify the permissions of the `authorized_keys` file:

user@remote_host:~$ ls -l .ssh/authorized_keys
-rw------- 1 user user 1194 Dec  6 09:39 .ssh/authorized_keys

Alternatively, you can use the `ssh-copy-id` command to transfer your key:

user@remote_host:~$ ssh-copy-id <username>@vscX.vsc.ac.at  # X denotes the cluster number

For example:

user@remote_host:~$ ssh-copy-id <username>@vsc5.vsc.ac.at   # The 5 indicates VSC-5

To use SSH keys:

• They may be added to an `ssh-agent`, which many window managers run by default. The `ssh-agent` prompts for your passphrase once and caches it for subsequent connections.
• Alternatively, specify the SSH key using the `-i` parameter or configure it in `~/.ssh/config`.

ssh -p 27 <username>@vscX.vsc.ac.at   # Replace vscX with the cluster name

For example:

ssh -p 27 <username>@vsc5.vsc.ac.at   # The 5 indicates VSC-5

You can use SSH keys even when connecting through one or more intermediate hosts. Use the `-J` option to specify the jump host. Ensure the public key is added to the `authorized_keys` file on all intermediate hosts.

You may specify parameters for each host in `~/.ssh/config` on your local machine(also visible with `man ssh_config`). Example configuration:

Host vsc5.vsc.ac.at vsc5
  Port 27
  User vsc_username
#  ForwardAgent yes
  IdentityFile id_rsa
  IdentitiesOnly yes
#  ForwardX11 yes

To configure automatic use of a jump host:

Host vsc5.vsc.ac.at vsc5
  User vsc_username
  ProxyJump login.univie.ac.at

Host login.univie.ac.at
  User uni_username

• While it is technically possible to create an SSH key without a passphrase, doing so would compromise security, as anyone with the key could establish a connection.
• Forwarding SSH keys, such as by aliasing the `ssh` command, is discouraged, especially when connecting to less secure servers. An attacker with administrator access could exploit forwarded keys.
• One of the most significant security risks is creating a passphrase-less SSH key and copying the public key directly into the `authorized_keys` file on the same server. This practice, though convenient, allows anyone with access to the account to connect from any location indefinitely. If necessary, combine this method with host access restrictions, e.g., in `~/.ssh/authorized_keys`: `from=“*.trusted.host.example.com”` (refer to man sshd for more information).