SSH install fails for GitHub Enterprise Data Residency (custom SSH username)

[dotned]

Problem

skillshare install fails when the source is a GitHub Enterprise (GHE) instance using Data Residency, because these instances require a custom SSH username rather than the standard git@.

GHE Data Residency instances use the subdomain as the SSH username. For example, an instance at acme.ghe.com requires SSH connections as acme@acme.ghe.com — the server rejects git@acme.ghe.com entirely.

Reproduction (extrapolated, not tested against the fix)

# This is how the remote looks in .git/config for a GHE DR instance:
# acme@acme.ghe.com:MyOrg/my-skills.git

# Attempting to install via SSH fails:
skillshare install git@acme.ghe.com:MyOrg/my-skills --track
# ✗ failed to clone repository: Could not read from remote repository.

# Using the actual username format isn't recognised:
skillshare install acme@acme.ghe.com:MyOrg/my-skills --track
# ✗ invalid source / fails to parse

Root Cause

In internal/install/source.go:

1. Line 56 — the SSH regex only matches the literal git@ prefix:

   var gitSSHPattern = regexp.MustCompile(`^git@([^:]+):([^/]+)/(.+?)(?:\.git)?(?://(.+))?$`)

2. Line 182 — the prefix check only recognises git@:

   strings.HasPrefix(input, "git@") ||

3. Line 312 — the clone URL is reconstructed with hardcoded git@:

   source.CloneURL = fmt.Sprintf("git@%s:%s/%s.git", host, owner, repo)

Suggested Fix

Generalise the SSH pattern to accept any username, and preserve it in the clone URL:

// Accept any user@host: format (captures username separately)
var gitSSHPattern = regexp.MustCompile(`^([^@]+)@([^:]+):([^/]+)/(.+?)(?:\.git)?(?://(.+))?$`)

And in parseGitSSH, preserve the original username:

source.CloneURL = fmt.Sprintf("%s@%s:%s/%s.git", user, host, owner, repo)

The prefix check (line 182) should match any <something>@<something>: pattern rather than just git@.

Why This Matters

GitHub Enterprise with Data Residency is GitHub's model for regulated industries and data sovereignty. These instances are becoming more common. The SSH username is assigned by the platform (matching the subdomain) and cannot be changed to git@.

Backwards Compatibility

This change is fully backwards-compatible — git@github.com:user/repo still matches the generalised pattern. It simply stops rejecting other valid SSH usernames.

[runkids]

Fixed in v0.20.2 Custom SSH usernames + *.ghe.com hosts now supported. Give it a try and let me know!

[dotned]

SSH install with a custom username now works in v0.20.2, thanks for the fix.

Tested successfully with:

skillshare install acme@acme.ghe.com:Acme/skills -s example-pr-description

Cloned from GHE, discovered skills, installed the selected one. Clean audit.

However, I've found a related bug: using -s to select a specific skill also installs all agents from the repo. Adding --kind skill suppresses this:

skillshare install acme@acme.ghe.com:Acme/skills -s example-pr-description --kind skill

This only installs the skill as expected. I'll raise the -s behaviour separately.

[runkids]

Thanks! Will check this issue!