Employees can get a Yubikey hardware key for free at the servicedesk in Forum.

With that key, you can implement multifactor authentication for your SSH connections.

Depending on you choices and setup, you can make it very secure, so that without the key, pin and password your SSH key won't be able to be used.

The steps below are adaptations of https://developers.yubico.com/SSH/Securing_SSH_with_FIDO2.html

=== Different levels of security/annoyance ===
There are different levels of security you can apply, each being more secure, but also introducing an extra step before you have an active session.

There a three "interactions" that can be used:

# Enforce/use a password to unlock your SSH key
# Enforce/use a PIN to unlock the hardware key
# Enforce/use touching the hardware key to get access

This then leads to the following 4 scenarios:

# Use SSH key password, pin and touch for each new SSH session (no SSH agent)
# Use pin and touch for each new SSH session (use SSH agent for password)
# Use touch for each new SSH session (use SSH agent for password, but no PIN enforcement in key)
# Use SSH key password and touch for first SSH session (pass in SSH agent, no PIN and touch enforcement in key)

The last one is the least intrusive, and as an attacker would need physical access to your device to circumvent your security, this is probably fine for most people.

This is thus the scenario that we'll describe below in detail.

For scenario 1 & 2, add <code>-O verify-required</code> to the <code>ssh-keygen</code> command to enforce PIN enforcement in key.

For scenarios 1, 2 & 3, do not add <code>-O no-touch-required</code> to the <code>ssh-keygen</code> command to enforce touch enforcement in key.

=== Linux ===

==== Create your key: ====
(do this on your laptop or desktop)
ssh-keygen -t ed25519-sk -O resident -O no-touch-required -O application=ssh:anunna.wur.nl -C "[Your comment to identify this key on the server]"
The options are:

* <code>-t ed25519-sk</code> : Type of key, this is the more secure option
* <code>-O resident</code> : Store the SSH key on your hardware key, makes it easier to use on another machine
* <code>-O no-touch-required</code> : No need to touch the hardware key every time
* <code>-O application=ssh:anunna.wur.nl</code> : identifier for the key on your hardware key
* <code>-C "[Your comment to identify this key on the server]"</code> : identifier for the key on the server

An example exchange looks like this:
haars001@L0160372:~ % ssh-keygen -t ed25519-sk -O resident -O no-touch-required -O application=ssh:anunna.wur.nl -C "jan.vanhaarst@wur.nl"
Generating public/private ed25519-sk key pair.
You may need to touch your authenticator to authorize key generation.
Enter PIN for authenticator:
You may need to touch your authenticator again to authorize key generation.
Enter file in which to save the key (/Users/haars001/.ssh/id_ed25519_sk):
Enter passphrase for "/Users/haars001/.ssh/id_ed25519_sk" (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /Users/haars001/.ssh/id_ed25519_sk
Your public key has been saved in /Users/haars001/.ssh/id_ed25519_sk.pub

Copy your key:

To be able to log in, the server will have to have the public part of your key.

For that, copy the contents of your public key, in my case <code>/Users/haars001/.ssh/id_ed25519_sk.pub</code> to <code>$HOME/.ssh/authorized_keys</code>

To allow touchless entry, we'll need to tell the SSH daemon to allow that:
# Copy over key
ssh -o ClearAllForwardings=yes login.anunna.wur.nl "umask 0077; mkdir -p ~/.ssh; echo 'no-touch-required $(cat ~/.ssh/id_ed25519_sk.pub)' >> ~/.ssh/authorized_keys"
# Check for key
ssh login.anunna.wur.nl 'tail -1 .ssh/authorized_keys'

=== MacOS ===
For MacOS, we can mostly do the same as for Linux, except that we will have to install openssh, as the default SSH stack doesn't work with hardware keys.

So:
brew install openssh
Besides that, you will have to add this snippet to your .zshrc file, otherwise the default ssh-agent will be used:
# Use Homebrew's ssh-agent instead of Apple's
if [ -z "$SSH_AGENT_PID" ] || ! ps -p "$SSH_AGENT_PID" > /dev/null 2>&1; then
# Kill Apple's agent
pkill -u $USER /usr/bin/ssh-agent 2>/dev/null
# Start Homebrew's
eval "$($(brew --prefix openssh)/bin/ssh-agent -s)"
fi

=== Windows ===
(needs to be filled by a Windows user)

2026-03-03T09:05:47Z

Haars0011:

XFCE job info

Linux desktop

2026-03-03T09:04:14Z

Haars0011:

Linux desktop

2026-03-03T09:03:49Z

Haars0011: Added form info

File:XFCE form extended.png

2026-03-03T09:02:47Z

Haars0011:

XFCE form extended

File:Basic XFCE form.png

2026-03-03T08:59:05Z

Haars0011:

Basic XFCE form

File:XFCE tile.png

2026-03-03T08:56:55Z

Haars0011:

XFCE tile

2025-07-07T11:32:16Z

Haars0011: Add iRods

Anunna currently has multiple filesystem mounts that are available cluster-wide:

== Global ==
* /home - This mount uses NFS to mount the home directories directly from the active master. Each user has a 200G quota for this filesystem, as it is regularly backed up to tape, and can reliably be restored from up to a week's history.

* /shared - This mount provides a consistent set of binaries for the entire cluster.

* /lustre - This large mount uses the Lustre parallel filesystem to provide files from multiple redundant servers. Access is provided per group, thus:
/lustre/[level]/[partner]/[unit]
e.g.
/lustre/backup/WUR/ABGC/
It comprises of two major parts (and some minor):
* /lustre/'''nobackup''' - This is the 'normal' filesystem for Lustre - no backups, just stored on the filesystem. Without having a backup needed, the cost of data here is not as much as under /lustre/backup, but in case of disaster cannot be recovered.
* /lustre/'''backup''' - In case of disaster, this data is stored a second time on a separate machine. Whilst this backup is purely in case of complete tragedy (such as some immense filesystem error, or multiple component failure), it can potentially be used to revert mistakes if you are very fast about reporting them. There is however no guarantee of this service.
* /lustre/'''shared''' - Same as /lustre/backup, except publicly available. This is where truly shared data lives that isn't assigned to a specific group.

And additionally:
* /lustre/'''scratch''' - Files here may be removed after some time if the filesystem gets too full (Typically 30 days). You should tidy up this data yourself once work is complete.

=== Private shared directories ===
If you are working with a group of users on a similar project, you might consider making a [[Shared_folders|Shared directory]] to coordinate. Information on how to do so is in the linked article.

== Local ==
Specific to certain machines are some other filesystems that are available to you:
* '''/archive''' - an archive mount only accessible from the login nodes. The cost of storing data here is less than on Lustre, but it cannot be used for compute work. This location is only available to WUR users. Files are able to be reverted via backup, however this only comes in fortnightly (14 day) intervals.

* /tmp - On each worker node there is a /tmp mount that can be used for temporary local caching. Be advised that you should clean this up, lest your files become a hindrance to other users. You can request a node with free space in your sbatch script like so:
<pre>
#SBATCH --tmp=<required space>
</pre>

* /dev/shm - On each worker you may also create a virtual filesystem directly into memory, for extremely fast data access. Be advised that this will count against the memory used for your job, but it is also the fastest available filesystem if needed.

== iRods ==
On Anunna we host our own iRods instance.

With that you can push data to the WUR tape storage for archiving at very low cost.

More info on how, please see https://irods.wurnet.nl/.

The best course of action is to loosely follow the course, using your own data, and use your personal space for data upload and transfer to tape.

Be sure to check whether the data is correctly stored on tape before you remove your data!

== See also ==
* [[Tariffs | Costs associated with resource usage]]

== External links ==
* [http://wiki.lustre.org/index.php/Main_Page Lustre website]

Filesystems

2025-07-07T11:28:35Z

Haars0011: Updated /archive

Anunna currently has multiple filesystem mounts that are available cluster-wide:

== Global ==
* /home - This mount uses NFS to mount the home directories directly from the active master. Each user has a 200G quota for this filesystem, as it is regularly backed up to tape, and can reliably be restored from up to a week's history.

* /shared - This mount provides a consistent set of binaries for the entire cluster.

* /lustre - This large mount uses the Lustre parallel filesystem to provide files from multiple redundant servers. Access is provided per group, thus:
/lustre/[level]/[partner]/[unit]
e.g.
/lustre/backup/WUR/ABGC/
It comprises of two major parts (and some minor):
* /lustre/'''nobackup''' - This is the 'normal' filesystem for Lustre - no backups, just stored on the filesystem. Without having a backup needed, the cost of data here is not as much as under /lustre/backup, but in case of disaster cannot be recovered.
* /lustre/'''backup''' - In case of disaster, this data is stored a second time on a separate machine. Whilst this backup is purely in case of complete tragedy (such as some immense filesystem error, or multiple component failure), it can potentially be used to revert mistakes if you are very fast about reporting them. There is however no guarantee of this service.
* /lustre/'''shared''' - Same as /lustre/backup, except publicly available. This is where truly shared data lives that isn't assigned to a specific group.

And additionally:
* /lustre/'''scratch''' - Files here may be removed after some time if the filesystem gets too full (Typically 30 days). You should tidy up this data yourself once work is complete.

=== Private shared directories ===
If you are working with a group of users on a similar project, you might consider making a [[Shared_folders|Shared directory]] to coordinate. Information on how to do so is in the linked article.

== Local ==
Specific to certain machines are some other filesystems that are available to you:
* '''/archive''' - an archive mount only accessible from the login nodes. The cost of storing data here is less than on Lustre, but it cannot be used for compute work. This location is only available to WUR users. Files are able to be reverted via backup, however this only comes in fortnightly (14 day) intervals.

* /tmp - On each worker node there is a /tmp mount that can be used for temporary local caching. Be advised that you should clean this up, lest your files become a hindrance to other users. You can request a node with free space in your sbatch script like so:
<pre>
#SBATCH --tmp=<required space>
</pre>

* /dev/shm - On each worker you may also create a virtual filesystem directly into memory, for extremely fast data access. Be advised that this will count against the memory used for your job, but it is also the fastest available filesystem if needed.

== See also ==
* [[Tariffs | Costs associated with resource usage]]

== External links ==
* [http://wiki.lustre.org/index.php/Main_Page Lustre website]

Filesystems

2025-05-26T14:29:35Z

Haars0011:

Anunna currently has multiple filesystem mounts that are available cluster-wide:

== Global ==
* /home - This mount uses NFS to mount the home directories directly from the active master. Each user has a 200G quota for this filesystem, as it is regularly backed up to tape, and can reliably be restored from up to a week's history.

* /shared - This mount provides a consistent set of binaries for the entire cluster.

* /lustre - This large mount uses the Lustre parallel filesystem to provide files from multiple redundant servers. Access is provided per group, thus:
/lustre/[level]/[partner]/[unit]
e.g.
/lustre/backup/WUR/ABGC/
It comprises of two major parts (and some minor):
* /lustre/'''nobackup''' - This is the 'normal' filesystem for Lustre - no backups, just stored on the filesystem. Without having a backup needed, the cost of data here is not as much as under /lustre/backup, but in case of disaster cannot be recovered.
* /lustre/'''backup''' - In case of disaster, this data is stored a second time on a separate machine. Whilst this backup is purely in case of complete tragedy (such as some immense filesystem error, or multiple component failure), it can potentially be used to revert mistakes if you are very fast about reporting them. There is however no guarantee of this service.
* /lustre/'''shared''' - Same as /lustre/backup, except publicly available. This is where truly shared data lives that isn't assigned to a specific group.

And additionally:
* /lustre/'''scratch''' - Files here may be removed after some time if the filesystem gets too full (Typically 30 days). You should tidy up this data yourself once work is complete.

=== Private shared directories ===
If you are working with a group of users on a similar project, you might consider making a [[Shared_folders|Shared directory]] to coordinate. Information on how to do so is in the linked article.

== Local ==
Specific to certain machines are some other filesystems that are available to you:
* /archive - an archive mount only accessible from the login nodes. Files here are sent to the PowerScale for deeper storage. The cost of storing data here is less than on Lustre, but it cannot be used for compute work. This location is only available to WUR users. Files are able to be reverted via snapshot, and there is a separated backup, however this only comes in fortnightly (14 day) intervals.

* /tmp - On each worker node there is a /tmp mount that can be used for temporary local caching. Be advised that you should clean this up, lest your files become a hindrance to other users. You can request a node with free space in your sbatch script like so:
<pre>
#SBATCH --tmp=<required space>
</pre>

* /dev/shm - On each worker you may also create a virtual filesystem directly into memory, for extremely fast data access. Be advised that this will count against the memory used for your job, but it is also the fastest available filesystem if needed.

== See also ==
* [[Tariffs | Costs associated with resource usage]]

== External links ==
* [http://wiki.lustre.org/index.php/Main_Page Lustre website]