Connecting to an HPC

The dashboard connects the same way a terminal ssh session does: with an SSH key pair, not a password.

If you already have a key you use for that cluster, skip to Adding a profile and point the SSH key path field at it.

SSH key setup

Gadi (NCI)

You will need an active NCI account and project first — a one-off setup done through NCI's own account system, separate from this app. Once you can log in with a password:

Generate a key pair on your own machine:

bash ssh-keygen -t ed25519 -f ~/.ssh/id_gadi

Set a passphrase when prompted. Recommended, not optional, for a key that gets you into an HPC system — the dashboard will prompt you to unlock it.

Copy the public key onto Gadi. This one password-based login is the only time you will need the password:

bash ssh-copy-id -i ~/.ssh/id_gadi.pub USERNAME@gadi.nci.org.au

No ssh-copy-id on your machine?

bash cat ~/.ssh/id_gadi.pub | ssh USERNAME@gadi.nci.org.au \ "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Confirm it works without a password prompt, other than your key's own passphrase:

bash ssh -i ~/.ssh/id_gadi USERNAME@gadi.nci.org.au

Setonix (Pawsey)

Same idea, different host. You will need an active Pawsey account first.

bash ssh-keygen -t ed25519 -f ~/.ssh/id_setonix
Append the public key to authorized_keys on Setonix. Pawsey's own docs are explicit that this must use >> (append), never > (overwrite), or you will wipe out any keys already registered there:

bash cat ~/.ssh/id_setonix.pub | ssh USERNAME@setonix.pawsey.org.au \ "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

bash ssh -i ~/.ssh/id_setonix USERNAME@setonix.pawsey.org.au

Either way, the dashboard only ever needs a path to your private key file — it is stored as a path in your profile, never the key contents.

Passphrase-protected keys

Supported. If the key is encrypted and not already unlocked in your SSH agent, the app prompts you once per session. The passphrase is held in memory only — never written to disk, never logged.

Host key verification

The first connection to a cluster records its host key in ~/.ssh/known_hosts, the same way ssh does. If a cluster later presents a different key the connection is refused with an explanation rather than a generic error — that is either a rebuilt server or something intercepting the connection, and it is worth checking with your system administrators before removing the old entry.

Adding a profile

A profile is one HPC connection: cluster, login details, and where your job logs live. Go to the Settings tab and fill in the form.

Field	What goes in it
Name	Anything memorable — just the label in the dropdown.
Host	The bare hostname, e.g. `gadi.nci.org.au`. No `https://`, no spaces; the form warns you if a URL looks pasted in.
Username	Your cluster login.
Scheduler	PBS for Gadi, Slurm for Setonix, or leave it unset. The current app still infers running/completed state from log activity; this setting does not query the scheduler.
Log directories	One path per line, where your `psutil_*.log` files are written — see the warning below.
Access method	`SFTP` connects directly over SSH with a key path and optional port. `Local mount` is for a filesystem already mounted locally, e.g. via `sshfs`.

The log directory trap

What kind of path depends on the access method:

For SFTP, these are real paths on the HPC itself.
For Local mount, these must be the path as it appears under your local mount point, not the remote HPC path.

The app does not join the remote path onto the mount point for you. A remote-style path on a local-mount profile points at the wrong local directory and can produce a missing-path warning or no jobs.

Test before saving

Click Test connection first. It tries the connection with whatever is currently in the form — including an unsaved draft — so you find out it is wrong before it is written to disk. Then Save profile.

Profiles are stored in profiles.toml in the app's local data directory, not synced anywhere.