Logging In
Here, you’ll find DNS names for our login nodes, sorted by cluster, their hostkey fingerprints and some examples showing how you can connect from the command line.
The Login Nodes
Names and Aliases
The proper DNS names of all frontend nodes and convenient aliases are provided in the table below. For square brackets with a number range, substitute any number in the range.
Cluster | Sub-cluster/Purpose | Aliases | Login node/s |
---|---|---|---|
SCC | login | login-mdc.hpc.gwdg.de login-mdc[1-2].hpc.gwdg.de gwdu[101-102].gwdg.de (deprecated) | gwdu[101-102].hpc.gwdg.de |
transfer | transfer-mdc.hpc.gwdg.de transfer-scc.gwdg.de gwdu108.gwdg.de (deprecated) | gwdu108.hpc.gwdg.de | |
CIDBN (restricted) | login-dbn02.hpc.gwdg.de | ||
sa/hh (restricted) | ngs01.hpc.gwdg.de | ||
NHR | Emmy Phase 1 | glogin-p1.hpc.gwdg.de glogin-p1.hlrn.de (deprecated) glogin[1-2].hlrn.de (deprecated) | glogin[1-2].hpc.gwdg.de |
Emmy Phase 2 | glogin-p2.hpc.gwdg.de glogin.hpc.gwdg.de glogin.hlrn.de (deprecated) glogin[3-8].hlrn.de (deprecated) | glogin[3-8].hpc.gwdg.de | |
Emmy Phase 3 | glogin-p3.hpc.gwdg.de | glogin[11-13].hpc.gwdg.de | |
Grete | glogin-gpu.hpc.gwdg.de | glogin[9-10].hpc.gwdg.de | |
KISSKI | tbd, for now: | glogin9.hpc.gwdg.de |
The login nodes marked as restricted in the table above are restricted to specific research groups. No one else can use them.
Aliases marked as deprecated will eventually disappear and stop working.
The login nodes for each NHR sub-cluster match the CPU architecture and software of their respective compute nodes. For example, Emmy Phase 1 and 2 run the same OS distribution and software, but have different CPU architectures (Skylake and Cascadelake). Compilers, by default, will either compile for the most generic version of the host’s architecture (poor performance) or for the exact CPU the host is running (which could then crash and/or have sub-optimal performance on a compute node with a different CPU architecture).
The SCC jumphosts are not part of the HPC clusters, but are needed to reach the SCC login nodes from outside GÖNET if you are not using VPN/Wireguard. Their DNS names and convenient aliases are in the table below:
Jumphost | Alias | Node name |
---|---|---|
login | login.gwdg.de | gwdu19.gwdg.de |
transfer | transfer.gwdg.de | gwdu20.gwdg.de |
The login
and transfer
jumphosts are not usable if your HPC access is granted via the HPC Project Portal
SSH key fingerprints
When first connecting, SSH will warn you that the host’s key is unknown and to make sure that it is correct, in order to avoid man-in-the-middle attacks. The following table contains all SHA-256 fingerprints of the host keys of the login nodes and jumphosts, arranged by key algorithm:
Node(s) | sha256 fingerprint ed25519 |
---|---|
gwdu[101-102].hpc.gwdg.de login-dbn02.hpc.gwdg.de glogin[1-13].hpc.gwdg.de | SHA256:PPK0aO2QZ/k4duUx18Pp5AOKG/gFEBHgw/bl8vg9oJk |
login.gwdg.de | SHA256:pY12krRnUkQ5lHNkRQSD/53wCdLO8gk3Fk82vpLGrp4 |
transfer.gwdg.de | SHA256:BLij4wfP5Jh0yCTsPtQN8Vqqt0ULd//IUsuKgZwKC1I |
gwdu108.hpc.gwdg.de | SHA256:Vylg/10HwDRxPUuOarcngRFH2jmDlnxWOqte7rnR3OI |
ngs01.hpc.gwdg.de | SHA256:yWUzxLXSIfXVuIX164VH8fHix5eNhBwWUr3CMCebQ0Y |
Node(s) | sha256 fingerprint rsa |
---|---|
gwdu[101-102].hpc.gwdg.de login-dbn02.hpc.gwdg.de glogin[1-13].hpc.gwdg.de | SHA256:EJyZLROEobVuCm2hSeEhcAIEB80PbZ85U4u4XNnvM4k |
login.gwdg.de | SHA256:ibxJ8Ol0zpi5eIYOFkSsgATptM3hpwAZY8CjJKV6BSY |
transfer.gwdg.de | SHA256:ijMXkXKWeCOJ9oUx/3PxMaulZj6qqjxezr0pwAkrans |
gwdu108.hpc.gwdg.de ngs01.hpc.gwdg.de | SHA256:RMgbCZ58sWYfZZv5T2DE9bOAFfN06xm9aMw1MjzjvLM |
Node(s) | sha256 fingerprint ecdsa |
---|---|
login.gwdg.de | SHA256:3EsHR/Hlfl3qoUTyWyNwpbvH8KPFZlpZw3q53iQs8AU |
transfer.gwdg.de | SHA256:r6pHUs7LBG8F0Duz+g75o+xiVIb4bVnseP4h8x2NpcY |
gwdu108.hpc.gwdg.de | SHA256:sIJNEepmILeEq/7Zqq4HCtpTM8L98arWTny5EiAX+gI |
ngs01.hpc.gwdg.de | SHA256:sIJNEepmILeEq/7Zqq4HCtpTM8L98arWTny5EiAX+gI |
The SSH key fingerprints are not the public keys themselves, but instead a checksum of them.
Fingerprints are a compact fixed-size way to check SSH keys, where as the keys themselves can be large enough to be unwieldy.
The lines in ~/.ssh/known_hosts
store the SSH public keys of each known server whose key has been accepted, rather than the fingerprints.
Do not copy and paste SSH key fingerprints into ~/.ssh/known_hosts
.
When you connect to a login node for the first time or when its SSH key changes, your SSH client will show you the new fingerprint (and the old one if it changed).
If it is your first time connecting to the node, it will ask you to check the fingerprint and accept it if it is correct.
If it has changed, it will tell you that you need to delete the old key in ~/.ssh/known_hosts
.
With OpenSSH’s client, it will print the line number of the line to be deleted and often a command you can use to remove the offending line/s more easily.
After that, you be able to confirm the SSH key on the next login with the fingerprints from the table above.
Example Logins with OpenSSH
Logging into an SCC login node
With the .ssh/config
file setup as in the Simple configuration examples, one would run just ssh SCC
.
If using the inside GÖNET config, the terminal session could look something like
jdoe1@laptop:~> ssh SCC
Enter passphrase for key '/home/jdoe1/.ssh/id_ed25519':
Last login: Wed Mar 20 09:05:45 2024 from 192.168.0.1
gwdu101:90 15:58:26 ~ >
If using the jumphost, it could look something like
jdoe1@laptop:~> ssh SCC
Enter passphrase for key '/home/jdoe1/.ssh/id_ed25519':
Enter passphrase for key '/home/jdoe1/.ssh/id_ed25519':
Last login: Wed Mar 20 09:05:45 2024 from 192.168.0.1
gwdu102:90 15:58:26 ~ >
If you are not using a configured Host
entry (not recommended) or want to know how to connect “manually” (useful for troubleshooting),
here is how you would do so (using a jumphost):
ssh jdoe1@login-mdc.hpc.gwdg.de -i .ssh/id_ed25519 -J jdoe1@login.gwdg.de
Or, if you are using an older SSH client:
ssh jdoe1@login-mdc.hpc.gwdg.de -i .ssh/id_ed25519 -o ProxyCommand="ssh -i .ssh/id-rsa -W %h:%p jdoe1@login.gwdg.de"
Make sure to replace jdoe1
with your actual username.
Logging into an NHR Grete login node
With the .ssh/config
file setup as in the Simple configuration examples, one would run just ssh Grete
.
The terminal session could look something like
jdoe1@laptop:~> ssh Grete
Enter passphrase for key '/home/jdoe1/.ssh/id_ed25519':
Last login: Wed Mar 20 09:05:45 2024 from 192.168.0.1
********************************************************************************
* *
* Welcome to HLRN-IV site Goettingen, *
* this is node glogin10 on "Emmy". *
* *
* Documentation -> https://www.hlrn.de/doc/ *
* Support -> mailto:nhr-support@gwdg.de *
* *
********************************************************************************
Found "/scratch/usr/gzadmfnord", setting $WORK
Found "/scratch/tmp/gzadmfnord", setting $TMPDIR
Module sw.skl loaded.
Module slurm (current version 23.11.4) loaded.
Module HLRNenv loaded.
Loading HLRNenv
Loading requirement: sw.skl slurm
glogin10:~ $
Logging into a specific node
This is essential if one needs to
- Reconnect to a tmux or screen session
- Reconnect to a session started by an IDE over SSH
- Use a dedicated login node for one’s research group (for those with such a login node)
- Use a login node with particular hardware
With the .ssh/config
file setup as in the Advanced configuration examples for all nodes configured individually, you would run just ssh NODE
where NODE
is the name of the node or a suitable alias.