Support authenticated hub sources (SSH / token-based)

[dotned]

Problem

Hub index fetch only supports unauthenticated HTTP GET or local file paths, which makes it hard to use private or enterprise Git hosting as a hub source.

In this case, pointing a hub at a GitHub Enterprise (GHE) instance doesn't work — raw HTTPS URLs return a 302 redirect to login even for internal repos. Similar behaviour would be expected from other enterprise/self-hosted platforms (GitLab, Bitbucket etc.) though those haven't been tested. SSH-style URLs aren't recognised in hub config at all.

There is existing support for GITHUB_TOKEN/SKILLSHARE_GIT_TOKEN env vars via applyHubAuthHeaders, which might work for some setups. In this case the GHE instance redirects before the headers get evaluated so it doesn't help — but it may already cover some scenarios.

Suggested phased approach

1. Phase 1: SSH hub source — detect SSH-style URLs in hub config, shallow-clone to a temp dir, read the index file. The plumbing already exists in cloneRepo (install_git.go) so this is mostly about reusing it in loadIndex. Probably the simpler change of the two.
2. Phase 2: Improved HTTPS auth — trickier, as it might need redirect handling, platform-specific API-based file fetch, or reworking how the existing token auth deals with redirecting endpoints.

Context

Speaking a little selfishly, the immediate need is a GHE instance where SSH is the primary access method. Installing individual skills over SSH works great (as of v0.20.2), but the hub index can't be fetched the same way. Phase 1 would unblock that — but it seemed worth framing more broadly since it likely affects anyone with secured repos. This may well be something you've already been thinking about.

Workaround

Using a local file path as the hub source, but that means each team member has to clone the hub repo locally first — which kind of defeats the purpose of a shared hub.

[runkids]

Phase 1 (SSH hub source) shipped in v0.20.4 🎉 Thanks @dotned for the clear phased framing — it mapped almost directly onto what landed.

You can now point a hub at an SSH URL and skillshare shallow-clones the repo with your SSH keys, then reads the index from inside it:

skillshare search react --hub git@ghe.corp.com:team/skills.git
skillshare hub add git@ghe.corp.com:team/skills.git//hubs/team.json --label ghe

Both scp-style (git@host:org/repo.git) and scheme-style (ssh://git@host/org/repo.git) URLs work. The index path inside the repo comes from the //path suffix and defaults to skillshare-hub.json at the repo root. In the web dashboard, an SSH hub source has to be saved before it can be browsed — the server only clones saved hubs.

That should unblock your GHE-over-SSH case directly.

Leaving this open for Phase 2 (token-based HTTPS auth + redirect handling for GHE/GitLab/Bitbucket endpoints that 302 to login before auth headers are evaluated), since that's the harder, still-unsolved half. Renaming to scope it to Phase 2 would be reasonable too if you'd rather track that separately.

Docs: hub command reference.

[dotned]

Thanks works well. I can now register a GHE hub via SSH, search it, and install skills from it on the CLI.

Worth noting: I tested with both GHE SSH URL forms — the long-form per-org alias (e.g. acme_123456@acme.ghe.com:MyOrg/skills.git) and the shorter general alias (e.g. acme@acme.ghe.com:MyOrg/skills.git). Both work fine.

I've noticed a couple of UI-specific issues when browsing a GHE-backed hub in the web UI (the skill preview modal can't fetch SKILL.md content because it's hardcoded to api.github.com). I'll raise those separately since they're distinct from the hub fetch problem this issue tracked.