Introduction

LRZ offers secure access to the HPC systems from outside via SSH ("secure shell"):

Password authentication using user name and password which was set in the LRZ IDM Portal. How to do this is described in the section "Basic usage" below. Most users will use this method.

For advanced users with special requirements LRZ also provides ssh-key login. If you want to use ssh keys, see chapter 3 below. We strongly discourage this method due to additional security risks like stolen and compromized ssh keys.

The following features of secure shell are relevant for users of LRZ HPC systems:

• encrypted transfer of passwords and data
• tunneling of services (in particular X11 graphics display) over the secure shell network port
• usage of the version 2 protocol of ssh. Version 1 is not supported at LRZ, since not sufficiently secure.

Secure shell has superseded other, insecure protocols like rsh and telnet, which are not supported anymore at LRZ.

Usage

Installation on client system (your desktop)

While secure shell is installed by default on LRZ systems, it may be necessary to install it on your system.

• Linux Systems: Most distributions contain an ssh client, but it may not have been installed. Please use the distribution-specific installation program to install the client
• Windows Systems: Various free implementations are available on the internet, for example PuTTY or MobaXterm. An alternative is to install the Windows subsystem for Linux (WSL).
• If you have a C compiler on your system, you can also install e.g. portable openssh from source.

Basic usage

Basic usage of ssh is very simple: Issue the command

$ ssh <LRZaccount>@<targetLRZsystem> 

You will be asked for your SIM password.  If the authentication is successfully concluded, you have a login shell on the target system. The target system typically must be specified with its full domain name.

A secure copy mechanism is also provided:

$ scp <myfile> <LRZaccount>@<targetLRZsystem>:<remotedirectory>
$ scp <LRZaccount>@<targetLRZsystem>:<remotedirectory> <myfile>

scp cannot be invoked on the LRZ system, because all outgoing connections are blocked. You have to use it on your local computer. Windows users can also use WinSCP or MobaXterm

The upper command will, for example, copy the local file <myfile> to the directory ~/<remotedirectory> on the remote system. This directory must exist prior to the copy attempt.

For additional security we provide the public system keys for SuperMUC-NG and Linux Cluster login nodes which can be added into the ~/.ssh/known_hosts file (you may need to generate the .ssh directory if it does not exist yet) on your local machine.

• Public keys for SuperMUC-NG login nodes
• Public keys for Linux Cluster login nodes

Policies for SSH public-key authentication

Configuration of SSH public-key authentication for access to LRZ systems from outside

The variant described here deploys the portable openssh implementation for this purpose. Before using secure shell, you will need to configure the software. The configuration starts on your own workstation/desktop (aka the client), other items need to be performed on the target LRZ system itself. While the ssh command will also work without these customization steps, usage is made easier by performing it. Here is the sequence of commands you need to perform (using the example of ecdsa); the leftmost column of the table indicates where the respective commands must be executed.

Client (your desktop) is a LINUX system

ssh-keygen -t ecdsa -b 521 -a 100

Generating public/private ecdsa key pair.
Enter file in which to save the key (/home/myaccount/.ssh/id_ecdsa)

Enter passphrase (empty for no passphrase):

ssh-copy-id -i /home/myaccount/.ssh/id_ecdsa <user>@<targetsystem>

Number of key(s) added: 1

Client (your desktop) is a WINDOWS system

mkdir -p ~/.ssh
chgrp $(id -g -n) ~/.ssh
chmod o-rwx,g-w ~
chmod go-rwx ~/.ssh

pscp c:\path_to_key\name_of_key.pub <user>@<targetsystem>:.ssh/

cd ~/.ssh
cat name_of_key.pub >> authorized_keys
rm name_of_key.pub

Per-session activity

At the beginning of your day's session please perform the following commands (LINUX system):

eval $(ssh-agent -s)

eval `ssh-agent -c`

ssh-add

Subsequent ssh commands can then be executed in the same shell without needing to re-authenticate. For other shells, you need to set the environment variables SSH_AUTH_SOCK and SSH_AGENT_PID to the same values as in the shell that started the agent, and export them (this can be automated).

LRZ internal configuration

This section is only relevant for setting ssh up to work without passwords (and without ssh agent) inside the cluster. This is needed for e.g. batch process startup in some commercial applications). None of the keys (public or private) generated here shall be transferred outside the cluster, since this may incur security problems. The following commands must therefore be executed on the LRZ target system.

cd $HOME/.ssh
ssh-keygen -t ecdsa

Generating public/private ecdsa key pair.
Enter file in which to save the key (/home/myaccount/.ssh/id_ecdsa)

Enter passphrase (empty for no passphrase):

cd ~/.ssh
cat id_ecdsa.pub >> authorized_keys

Special topics

This section discusses special usage patterns that are relevant if a system only allows one-way connections (such as the SuperMUC, which does not allow outgoing traffic). As a consequence, tools (such as distributed source control packages) which use ssh as the underlying transport protocol may fail.

Port forwarding

If outgoing traffic is disallowed for a <PORT>, you can set up port forwarding using an incoming connection e.g.,

ssh -R <NEW_PORT>:<URL>:<PORT> <Your Login>@<Login Node>.lrz.de

the shell generated on the target system will then allow you to specify localhost:<NEW_PORT> in place of the original <URL>:<PORT> because the ssh connection forwards the former to the latter through a tunnel connection.

Note that <NEW_PORT> must not be in use by someone else; you will see a ssh-generated error message if this is the case. If your software stores <NEW_PORT> away somewhere, you will need to do additional configuration changes if you need to change the value of <NEW_PORT>.

If incoming traffic is disallowed for a <PORT>, the following command can be used:

ssh -L <NEW_PORT>:localhost:<PORT> <Your Login>@<Login Node>.lrz.de

On a separate local shell, it is then possible to access the service running on <PORT> of the remote machine via localhost:<NEW_PORT>.

Data access via sshfs

If port forwarding fails and your software only requires access to data on disk, using a ssh-tunnelled mount may be sufficient. The sshfs command, which typically is delivered with modern Linux distributions can be used for this purpose:

sshfs [-o workaround=rename]  <Your Login>@<Login Node>.lrz.de:<Path name> <Mount Point>

will mount a path on the remote system to a local mount point; if the remote path is omitted the HOME directory will be used. File access permissions should be taken over from the remote system. Once the mount is established, you can run your software locally and access data via the mount; note that some packages may need additional workaround options such as the one optionally specified above. You can remove the mount via the command

fusermount -u <Mount Point> 

Troubleshooting and optional features

Login fails

If the secure shell command does not work as expected, please

• Try a ping command to the target system
• Try a host command with the target system as the argument (local DNS configuration).
• Check whether any maintenance measures have been announced for the target system.
• Check which authentication method is triggered (password or key); a verbosity option (see below) can help with this.
• Check whether suitably restrictive permissions are set on your $HOME as well as your $HOME/.ssh directory (see above).
• Finally, try one of the -v, -vv or -vvv option (increasing verbosity) on the ssh command.
• If you decide to contact the LRZ Service Desk, please supply the output of -vvv.
  

Connections are disrupted after some time

If ssh-based connections (including sshfs mounts) tend to hang if left unused for a time, adding the option

 ServerAliveInterval 100

to your (workstation-local) .ssh/config file may help.

X11 does not work

If opening new X windows does not work, please check the following:

• Either, specify the -Y switch in your ssh command line, or, add an entry of the form

   ForwardX11Trusted yes

     
  to your .ssh/config file. This setting assumes that you trust our administrators as well as our security procedures, since technically this opens a tunnel that allows an attack on your X11 display. You can consider using the -X switch (or the ForwardX11 configuration file setting) instead, but a great many X11 clients will not work at all then.

• If you have a Microsoft Windows client, you need to activate X11 tunnelling in the PuTTY configuration, as well as have a X Window server (e.g. Xming) running locally.

• If you got an error message like

  error in locking authority file
  /dss/dsshome1/.../.Xauthority

  at login, please check your HOME filesystem quota. If this command indicates an overflow, you need to delete files from your HOME directory. Multiple simultaneous logins to the target system may also provoke the above error message (in this case due to file locking). In the latter case, please exit the failed shell and start a new one.

Optional measure to enhance your security

In order to permit connections from particular sources, each key contained in the authorized keys file on the HPC system may be prepended with a non-trivial from clause. In case of a stolen private key, a third party will not be able to use it to access the HPC system from a different computer. For example, the default entry in authorized_keys

ecdsa-sha2-nistp521 <key value> <user>@<host>

will be changed to:

from="<IP address of your computer>" ecdsa-sha2-nistp521 <key value> <user>@<host>