fix(config): resolve saved relative SSH key paths consistently

Open Beginner friendly
  • Is something wrong?
#19 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
72/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
bash, shell
Domain
cli

Research direction

Start with scripts/mac/lib.sh, where new_config saves the SSH key path and load_config later reads it; the Linux entry point uses this shared implementation. Trace how the path is validated and stored, then add regression coverage for creating the config from one directory and loading it from another. Done when the relative-path case retains the same key identity across directories and the existing absolute-path case still works.

Written by the indexing model from the issue text.

Description

Summary

new-config.sh accepts a relative SSH key path and reports success, but stores it unchanged in headless.env. Later operations resolve that path against their invoking directory. The saved configuration and key can therefore become unusable solely because the operator runs the next command from a different directory.

Tested source and environment

Current main at fe1a381c6f382ec3c9822da0e706484414bc63e0, with no published release. Reproduced through Crabbox 0.82.0 in an Ubuntu 26.04 ARM64 container using the real Bash library, Git, Python, and OpenSSH tooling. No target connection or real secret store was needed.

Reproduction

From the checkout, set repo to its absolute path and use disposable directories:

repo=$PWD
work=$(mktemp -d)
mkdir "$work/creator" "$work/elsewhere"
ssh-keygen -q -t ed25519 -N '' -C relative-path-fixture -f "$work/creator/key"
(cd "$work/creator" && "$repo/skills/headless/scripts/linux/new-config.sh" \
  "$work/config" --address example.invalid --login admin \
  --password-ref cmd:false --ssh-key key)
(cd "$work/creator" && bash -c '. "$1/skills/headless/scripts/linux/lib.sh"; load_config "$2"' probe "$repo" "$work/config")
(cd "$work/elsewhere" && bash -c '. "$1/skills/headless/scripts/linux/lib.sh"; load_config "$2"' probe "$repo" "$work/config")
rm -rf "$work"

Generation and loading from the creation directory succeed. Loading the same configuration from the other directory fails because SSH_KEY key or its .pub is missing. Neither file moved. This failure happens in load_config, before any network operation.

The automated probe also repeated generation with an absolute SSH key path and loaded that configuration from the other directory successfully:

RELATIVE stored='SSH_KEY=key' creation_cwd_exit=0 elsewhere_cwd_exit=1
ABSOLUTE elsewhere_cwd_exit=0

Expected behavior and cause

Once a supplied key path has been accepted and saved, subsequent commands taking the configuration directory should find the same key independently of their process directory. Resolve the accepted path when creating the configuration, or consistently define and apply another stable path base. Rejecting an unsupported relative path before writing a successful configuration would also avoid this misleading success.

The shared scripts/mac/lib.sh reads the key relative to the current directory during new_config, writes the original SSH_KEY value to headless.env, and only expands ~/ during load_config. The Linux entry point uses this shared implementation. The executed proof covers that controller path; native target activation was not involved.

Workaround and validation

Pass an absolute key path. The absolute-path control directly succeeded from the other directory. Regression coverage should preserve both the accepted key identity and config usability when the next operation is invoked from a different directory.

Triage assessment

  • Impact level: P2
  • Assessment status: supported
  • Impact basis: An accepted relative key path makes every later configuration-loading operation fail from another working directory, despite unchanged configuration and key files.
  • Workaround status: available
  • Workaround basis: An absolute-path configuration loaded successfully from the other directory in the same probe.
Dominant language
Shell
Stars
92
Forks
6
Avg merge
25m
Merged PRs (30d)
5

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 kunchenguid/headless

All issues in kunchenguid/headless

Similar issues

More Shell/Bash issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.