Best practice for managing SSH keys across multiple GitHub repositories?

[MandeepDalavi]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Other

Discussion Details

I'm using GitHub Actions to deploy multiple applications to the same VPS/cPanel server over SSH.

Currently, each repository has its own private key stored as a GitHub Secret, even though they all deploy to the same server.

I'm wondering what the community considers the best practice here.

Questions:

• Do you generate a different SSH key pair for every repository?
• Or do you reuse the same deployment key across multiple repositories?
• How do you balance security and maintainability?
• Any recommendations for rotating keys without breaking existing deployment workflows?

I'd love to hear how others handle this in production.

[Rohanf4f]

SSH Key Management for Multi-Repo Deployments to a Shared Server

One key per repo vs. one shared key

Best practice: one dedicated key pair per repository (or per deployment pipeline).

Reusing a single key across multiple repos is convenient, but it creates a "blast radius" problem — if one repo's secret leaks (compromised Action, malicious PR from a fork, leaked log, etc.), the attacker gets SSH access to every app on that server, not just the one that leaked. Since you're deploying to a shared VPS anyway, that's the scenario you most want to avoid.

So the general recommendation is:

• Generate a separate ed25519 key pair per repo.
• Add each public key to the server, but scope it down (see below) rather than giving it full account access.
• Store the private key as a repo-level GitHub Secret, not an org-wide secret shared across repos.

Scoping keys instead of just trusting isolation

Just having separate keys isn't enough if every key still has full shell access as the same deploy user. On the server side (~/.ssh/authorized_keys for your deploy user), you can restrict what each key is allowed to do using command= and option flags:

command="/home/user/deploy-scripts/deploy-app1.sh",no-port-forwarding,no-X11-forwarding,no-agent-forwarding restrict ssh-ed25519 AAAA... app1-deploy-key

This means even if app1's key leaks, it can only run that one deploy script — it can't be used to open an arbitrary shell or touch other apps' directories. This is arguably more important than the "one key per repo" rule by itself.

If your cPanel setup makes editing authorized_keys directly with command= awkward, another common pattern is:

• One low-privilege deploy user per application (not just one shared deploy user for everything), each with its own home directory scoped to that app.
• Restrict permissions/ownership so that user can only touch its own app's directory.
• Each repo's key then only grants access to that dedicated user, so isolation happens at the OS user/permission level even without command= restrictions.

Maintainability trade-off

The honest trade-off: yes, N repos means N key pairs to manage instead of 1. In practice this is manageable because:

• You only generate a key once per repo:

  ssh-keygen -t ed25519 -f app_deploy_key -C "app1-deploy"
  

• Tools like appleboy/ssh-action or plain ssh/rsync steps don't care how many keys exist — each workflow just references its own secret.
• If you want central visibility without sharing key material, keep an internal doc/runbook (or a private "infra" repo) listing which key belongs to which app/server, purely for audit purposes. The private key itself still only lives in that repo's GitHub Secrets.

Rotating keys without breaking deployments

The safe rotation pattern is overlap, don't swap:

1. Generate a new key pair for the repo.
2. Add the new public key to authorized_keys on the server, alongside the old one (don't remove the old one yet).
3. Update the GitHub Secret with the new private key.
4. Trigger a deploy (or wait for the next scheduled one) and confirm it succeeds with the new key.
5. Only after that succeeds, remove the old public key from authorized_keys.

This gives you a safety net — if step 3/4 has a typo or the new key wasn't added correctly, the old key is still there and your next deploy doesn't just hard-fail. Some teams script this rotation (a small Ansible/shell script that appends the new key and only prunes keys older than N days) so it's not a manual SSH-in-and-edit-a-file chore every time.

Quick summary

Practice	Recommended
Shared key across all repos	❌ Avoid — one leak compromises everything
One key per repo	✅ Yes
Key scoped with command= / restricted user	✅✅ Even better than just "different key"
Org-wide secret for the key	❌ Prefer repo-level secrets
Hard swap during rotation	❌ Overlap old + new key during rotation instead