Hacktoberfest 2026：維護者為十月標記出來的 issue，仍然開放、適合新手。 瀏覽 Hacktoberfest issue

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

未關閉
  • 哪裡不對？
#245 0 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

還沒有人認領這個 Issue。

評估

難度
5/5
預估耗時
一週以上
新手友好度
12/100
Issue 類型
功能
描述清晰度
基本清楚
活躍度
活躍
領域
authentication, security

研究方向

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.

由索引模型根據 Issue 內容生成。

描述

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.

主要語言
C
星號
10
分支
8
平均合併
21 分鐘
30 天內合併 PR
1

環境準備

這個專案沒有提供開發容器、Dockerfile 或貢獻指南，環境需要你自己搭建：先看它的 README，通用步驟見我們的新手貢獻指南。

從這裡開始

  1. 先讀完整個 Issue，再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫，在一個分支上完成修改。
  4. 送出 Pull Request，並在描述裡引用這個 Issue 編號。

FriendsofECCE/ECCE 的其他 Issue

查看 FriendsofECCE/ECCE 的全部 Issue

相似的 Issue

更多 C Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。