Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Register Machines: set up ssh key login to a compute machine (keychain-stored passphrase)

Open
  • Is something wrong?
#245 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
12/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Domain
authentication, security

Research direction

This is design work spanning key creation, OS keychains on three platforms, and remote authorized_keys handling, so start by reading the proposal and agreeing scope with maintainers via #204 and #194. The payload names the sshd test containers in tests/transport/sshd, plus the existing AuthCache, passdialog and login path that the one-time password copy must reuse. Done would mean a key-only login succeeds with no password prompt, re-running the button does not duplicate the key, and the centre-policy message is shown correctly.

Written by the indexing model from the issue text.

Description

Goal

Make key-based ssh login to a compute machine (HPC cluster) easy to set up from Register Machines, so users do not type a password for every connection. Users must also not have to type a passphrase repeatedly.

Proposal

An opt-in button "Set up key login…" on the Connection tab of Register Machines. It is not done automatically.

  1. Key. If the user has no suitable key (~/.ssh/id_ed25519), create an ed25519 key with a passphrase.

  2. Passphrase storage. Store the passphrase in the operating system's keychain:

    • macOS Keychain
    • Windows Credential Manager
    • Secret Service / GNOME Keyring on Linux

    These unlock at desktop login, so in practice the passphrase is never typed again. Where no keychain is available, ECCE asks once per session and keeps it in memory (AuthCache), as it does for passwords today.

  3. Copy the public key. Log in once with the existing password login (ECCE's own ssh, AuthCache, passdialog), then append the public key to ~/.ssh/authorized_keys on the machine, as ssh-copy-id does:

    • create ~/.ssh with mode 700 and authorized_keys with mode 600;
    • do not add a key that is already present.

  4. Test. Try a key-only login and report the result plainly, including "the centre still requires a second factor".

Policies and limits

  • Centre policies. Some centres forbid keys without a passphrase. Others accept keys only through their own portal, where authorized_keys is ignored. The dialog states this and can show a link given in the site configuration for that machine.
  • Two-factor centres. At centres with a second factor, a key may replace the password but not the code. ECCE already logs in once per job (824b6262), not once per stream.
  • No passphrase-less default. Passphrase-less keys are not created by default. A deliberate choice for lab or shared accounts is possible, with a plain warning.
  • Standard key location. The key lives in the standard ~/.ssh location on every platform, so other ssh tools can use it.

Security

  • The private key and passphrase never leave the user's computer.
  • No credential is written to logs or temporary files.
  • The password used for the one-time copy goes through the existing login path only.

Tests

  • The sshd test containers (tests/transport/sshd): password-only and keyboard-interactive servers. After set-up, a key login succeeds and the password is not asked.
  • A centre that ignores authorized_keys is reported correctly.
  • Running the button again does not duplicate the key.
  • Keychain round trip on Linux CI (Secret Service), with macOS/Windows keychain access checked in their CI jobs.

Related: #204 (transport), #194 (credentials), first-start question #240.

Dominant language
C
Stars
10
Forks
8
Avg merge
21m
Merged PRs (30d)
1

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from FriendsofECCE/ECCE

All issues in FriendsofECCE/ECCE

Similar issues

More C issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.