DEV Community

Cover image for Securely Managing GitHub Access on Production Servers
Yousuf Basir
Yousuf Basir

Posted on

Securely Managing GitHub Access on Production Servers

#github #git #ssh #cybersecurity

This guide shows the correct, production-safe way to let a server clone and update private GitHub repositories using deploy keys and SSH aliases.

This approach works for:

  • single servers
  • multiple apps on one server
  • teams with shared infrastructure
  • long-lived production environments

Why This Matters

Common mistakes:

  • Using HTTPS with personal access tokens
  • Using one SSH key for all repositories
  • Logging in to GitHub from servers
  • Giving write access when read-only is enough

These mistakes increase blast radius.

Our goal:

If a server or key is compromised, only one repository is affected — nothing else.

Core Rules

We follow these rules strictly:

  1. One repository = one SSH key
  2. Servers never use personal GitHub accounts
  3. Deploy keys are read-only
  4. SSH aliases decide which key is used
  5. HTTPS is never used on production servers

Step 1 — Generate a Deploy Key (Server Side)

Log in to the server as the admin/deployment user (for example, dev).

Generate a new SSH key:

ssh-keygen -t ed25519 -C "deploy-myapp"
Enter fullscreen mode Exit fullscreen mode

When prompted for the file name, do not use the default key.

Use a repository-specific name:

/home/dev/.ssh/id_ed25519_myapp
Enter fullscreen mode Exit fullscreen mode

Leave the passphrase empty.

This creates:

~/.ssh/id_ed25519_myapp
~/.ssh/id_ed25519_myapp.pub
Enter fullscreen mode Exit fullscreen mode

Each repository must have its own unique key.

Step 2 — Configure an SSH Alias

When multiple SSH keys exist, Git needs help choosing the right one.
We solve this using SSH aliases.

Edit the SSH config file:

nano ~/.ssh/config
Enter fullscreen mode Exit fullscreen mode

Add a new section:

Host github.com-myapp
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_myapp
  IdentitiesOnly yes
Enter fullscreen mode Exit fullscreen mode

What this does:

  • github.com-myapp is an alias (not a real domain)
  • It forces SSH to use id_ed25519_myapp
  • Prevents Git from trying the wrong key

This is mandatory once you have more than one deploy key.

Step 3 — Add the Deploy Key to GitHub

On GitHub:

  1. Open the repository
  2. Go to Settings → Deploy keys
  3. Click Add deploy key
  4. Paste the public key: 
cat ~/.ssh/id_ed25519_myapp.pub
Enter fullscreen mode Exit fullscreen mode
  1. Give it a clear name (e.g. prod-server)
  2. Enable read-only access

Deploy keys are repository-scoped by design — this is a security feature.

Step 4 — Clone Using the SSH Alias (Not HTTPS)

❌ Do not use HTTPS
❌ Do not use the default GitHub SSH URL

Instead, clone using the alias:

git clone git@github.com-myapp:your-org/myapp.git
Enter fullscreen mode Exit fullscreen mode

What happens here:

  • github.com-myapp matches the SSH config
  • SSH selects the correct deploy key
  • The server can access only this repository

Step 5 — Consistent Naming (Strongly Recommended)

To avoid confusion, keep names aligned:

Item Example
SSH alias github.com-myapp
Key file id_ed25519_myapp
Repo name myapp

This becomes critical when managing many applications on the same server.

Why This Setup Is Secure

  • No personal GitHub accounts on servers
  • No long-lived access tokens
  • No shared SSH keys
  • One compromised key affects only one repo
  • Access can be revoked instantly from GitHub

This is least-privilege access, applied correctly.

How This Fits Into a Secure Deployment Workflow

In a hardened server setup:

  • Admin users clone and build apps
  • Service users never touch Git
  • Deploy keys are read-only
  • Runtime environments are isolated

This keeps code access, runtime access, and system access clearly separated.

Final Thoughts

Secure infrastructure is about boundaries, not convenience.

Using deploy keys with SSH aliases is slightly more work upfront —
but it prevents an entire class of security failures later.

If your production server ever needs GitHub access,
this is the correct way to do it.

Top comments (0)