github-private-repo-ssh-routing
Diagnose and manage SSH keys, host aliases, and Git remotes for GitHub private repositories in multi-repo environments. Use when deploy keys collide, a machine manages multiple private repos, automation or backup scripts push to GitHub, or errors like "Permission denied (publickey)" / "Repository not found" appear despite the repo existing.
Install via CLI (Recommended)
clawhub install openclaw/skills/skills/darinrowe/github-private-repo-ssh-routingGitHub Deploy Key Routing
Treat GitHub private repo access as a routing problem, not just a Git problem.
Core rules
- Use one deploy key per private repository unless a machine user is intentionally chosen.
- Use one SSH host alias per key.
- Point each repo remote at the correct alias explicitly.
- Do not rely on a catch-all
Host github.comwhen multiple deploy keys exist. - Verify SSH first, then Git, then push.
- If automation is involved, fix both the live repo remote and the config/script source that writes it.
Canonical pattern
Host github.com-backup
HostName github.com
User git
IdentityFile ~/.ssh/openclaw_backup_ed25519
IdentitiesOnly yes
git remote set-url origin [email protected]:OWNER/REPO.git
Use this skill when the machine has more than one private GitHub repo, more than one SSH key, or any recurring GitHub automation.
Quick triage
If you need the fastest route:
- Read
references/symptoms.mdand match the exact error. - Read
references/patterns.mdand compare the current alias + remote layout. - Read
references/decision-guide.mdonly if the identity model itself is still undecided. - Read
references/openclaw-automation.mdonly when a script, backup flow, or config value may be rewriting the remote.
Workflow
1. Identify the repo + remote actually in use
Check the local repo path, current remotes, and whether the failing action came from:
- an interactive repo command
- a backup/sync script
- a config file that stores the repo URL
- a cron/automation job
If the repo path and the config source differ, do not treat them as the same fix.
2. Identify the key-routing layer
Read references/patterns.md for the standard alias layout.
Read references/key-storage-by-system.md when OS-specific key locations or mixed Windows/WSL/macOS behavior may matter.
Ask:
- Which SSH alias is the repo using now?
- Which key does that alias select?
- Is that key actually authorized for this repo?
- Is a broad
Host github.comrule hijacking traffic?
3. Diagnose by symptom
Read references/symptoms.md and match the exact failure string before changing anything.
4. Choose the right identity model
Read references/decision-guide.md when the user is deciding between:
- deploy key
- personal SSH key
- machine user
Read references/identity-model-boundaries.md when the question is really about where SSH routing ends and GitHub API authority begins — especially for PR merge automation, release creation, or fine-grained PAT vs deploy key decisions.
5. Check automation-specific drift
Read references/openclaw-automation.md when the repo is used by OpenClaw backup/restore, plugins, cron jobs, or config-driven workflows.
6. Fix in the safe order
Metadata
Not sure this is the right skill?
Describe what you want to build — we'll match you to the best skill from 16,000+ options.
Find the right skillPaste this into your clawhub.json to enable this plugin.
{
"plugins": {
"official-darinrowe-github-private-repo-ssh-routing": {
"enabled": true,
"auto_update": true
}
}
}Related Skills
obsidian-official-cli-headless
Install and adapt the official Obsidian CLI for headless Linux servers by using a non-root user, Xvfb virtual display, ACL-based vault access, and an obs wrapper command. Use when the user wants the official Obsidian CLI (not notesmd-cli) on a Debian/Ubuntu-like machine without a normal desktop session, or when root/GUI/display constraints break native CLI use.
openclaw-backup-restore
Backup and restore OpenClaw configuration, agents, sessions, and workspace to/from a private Git repository. Use when the user wants to manually trigger a backup, migrate to a new machine, or restore from a previous state.
multi-agent-filesystem-governance
Govern filesystem organization and file-operation decisions in multi-agent environments. Use when deciding where files should live across agent-private workspaces, shared resources, archives, downloads, scripts, notes, knowledge vaults, and code project folders; when defining directory conventions; when triaging downloads; when preventing cross-agent overwrites; or when standardizing file placement and lifecycle rules for reusable agent setups.
git-backed-obsidian-cli-workflows
Use the official Obsidian CLI for note workflows in a Git-backed vault, including search, read, links/backlinks-style queries, daily-note operations, and lightweight note writes that auto-sync after successful write operations. Use when the official Obsidian CLI is already installed and usable on any supported environment, and the task is about querying or updating notes in an Obsidian vault with Git-backed backup behavior.
git-workflows-pro
Handle advanced git workflows and recovery tasks. Use when the user needs help with interactive rebase, commit cleanup, conflict resolution, reflog recovery, cherry-pick, stash, worktree, bisect, submodule vs subtree decisions, sparse checkout, branch archaeology, or undoing dangerous history mistakes in real repositories.