[Bug]: Default Git SSH signing relay fails with a ~/ private-key path #1723

What happened?

Git SSH signing fails inside a Linux workspace when the macOS host uses:

[user]
    signingkey = ~/.ssh/git_signing_ed25519
[gpg]
    format = ssh
[commit]
    gpgsign = true

The host and workspace use the same dotfiles, and the configured file is an OpenSSH private key in both environments. This setup uses private-key files directly, without an SSH agent.

Devsy’s SSH signing forwarding is enabled by default. The workspace’s effective gpg.ssh.program is devsy-ssh-signature.

The failure reproduces in a temporary Git repository, independently of the original project and its pre-commit hooks.

Changing the macOS host’s user.signingkey to its absolute private-key path made the same test succeed:

[user]
    signingkey = /Users/<user>/.ssh/git_signing_ed25519

What did you expect to happen instead?

The default signing relay should support the host’s valid Git SSH signing configuration, including a private-key path using ~/.

Git explicitly supports private-key paths in user.signingkey; an SSH agent is not required for this mode.

Git documentation

Steps to reproduce

1. On macOS, configure Git as shown above, using a valid, unencrypted OpenSSH private key. Use disposable keys when reproducing.
2. Apply the same dotfiles to a Linux workspace, with the private key present at the corresponding workspace path.
3. Connect through Devsy with its default SSH signing forwarding.
4. Run this Bash command inside the workspace. It creates and removes a temporary repository without modifying the current repository:

( sign_test_dir=$(mktemp -d) || exit; trap 'rm -rf -- "$sign_test_dir"' EXIT; git init -q "$sign_test_dir" && git -C "$sign_test_dir" -c user.name='Signing Test' -c user.email=signing-test@example.invalid commit-tree -S -m 'Signing test' "$(git -C "$sign_test_dir" mktree </dev/null)" >/dev/null && echo 'Signing OK' )

5. Observe the signing failure.
6. Change the macOS host’s user.signingkey to the absolute path of the same private key.
7. Run the same test again. It prints:

Signing OK

Error output / logs

The nested error, with the temporary path shortened:

signature server returned 500:
  rpc error: code = Unknown desc = get git ssh signature:
    failed to sign commit: exit status 255
    stderr:
      Couldn't load public key /var/folders/.../T/.git_signing_key_3611075085:
      No such file or directory

How often does this happen?

Repeatedly with the ~/ configuration. The same temporary-repository test succeeded after changing the host configuration to an absolute path.

Environment

• Devsy host CLI: v1.25.0-beta.3
• Host: macOS, ARM64
• Workspace: Linux
• Interface: CLI
• SSH agent: not used

Anything else?

Source inspection suggests the following failure mechanism:

• Git expands ~ using the workspace’s home directory.
• createSignatureRequestBody reads the workspace-local file, applies strings.TrimSpace, and sends its contents as PublicKey, without checking whether it is a public or private key.
• The host writes those contents to a temporary file and invokes ssh-keygen.

In a separate macOS experiment with a disposable OpenSSH private key, preserving the trailing newline allowed signing without an agent. Removing it reproduced the same error, even though the temporary file existed.

This supports the newline-corruption explanation, but the failed relay request’s temporary file was not captured directly.

The existing SSH signing E2E covers public-key paths with an SSH agent. It does not cover this private-key, shared-dotfiles configuration without an agent.

Using an absolute host private-key path is a verified workaround.

Thanks for all the recent work on Devsy, @skevetter! Given how actively development is moving, I thought reporting this as an issue would make it easier to fit into the ongoing work than opening a PR myself.