SSH Keys Explained: Private Git Repos vs CI/CD Deployments (The Right Way)

When working with servers, SSH keys solve two very different problems. Most confusion happens because people try to use the same key or same mental model for both.

This guide explains both cases clearly:

• Pulling a private Git repository directly from a server
• Deploying code to a server using CI/CD (GitHub Actions)

Same technology (SSH), different trust models, different keys, different responsibilities.

Mental Model (Before We Touch Commands)

Always ask one simple question:

Who is connecting to whom, and who must trust whom?

Once this clicks, SSH stops being confusing.

1️⃣ Pulling a Private Git Repository From the Server

Use case

Your server needs to run:

git pull

on a private GitHub repository.

This means:

• The server is the SSH client
• GitHub is the server being authenticated against

So GitHub must trust the server.

Correct approach

👉 Generate an SSH key on the server
👉 Tell GitHub to trust that key

Step 1: Generate SSH key on the server

On the server (as the deploy user, e.g. logiccraft):

ssh-keygen -t ed25519 -C "logiccraft-server"

Press Enter for:

• file location
• passphrase (optional)

This creates:

~/.ssh/id_ed25519        (private key)
~/.ssh/id_ed25519.pub    (public key)

The private key never leaves the server.

Step 2: Add the public key to GitHub (Deploy Key)

Copy the public key:

cat ~/.ssh/id_ed25519.pub

On GitHub:

• Repo → Settings
• Deploy Keys
• Add Deploy Key
• Paste the public key
• Enable Read access (or Write if needed)

✅ GitHub now trusts this server.

Step 3: Test from the server

ssh -T git@github.com
git pull

If it works → you’re done.

Key takeaway (important)

• This key lives on the server
• GitHub trusts the server
• Used only for git pull / git fetch
• Never used for deployments

2️⃣ CI/CD Deployments (GitHub Actions → Server)

This is a different problem.

Use case

GitHub Actions needs to run:

ssh logiccraft@your-server

in order to deploy code automatically.

Here:

• GitHub runner is the SSH client
• Your server must trust GitHub

Correct approach

👉 Generate one SSH key locally (no passphrase)
👉 Add its public key to the server
👉 Store its private key in GitHub Secrets

Step 1: Generate CI/CD key on your laptop

On your local machine:

ssh-keygen -t ed25519 -f ~/.ssh/logiccraft_ci_nopass -N ""

This creates:

logiccraft_ci_nopass        (private key)
logiccraft_ci_nopass.pub    (public key)

✅ No passphrase — required for automation.

Step 2: Add public key to the server

Copy the public key:

cat ~/.ssh/logiccraft_ci_nopass.pub

On the server:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys

Paste the public key on a new line, then:

chmod 600 ~/.ssh/authorized_keys

✅ The server now trusts GitHub Actions.

Step 3: Add private key to GitHub Secrets

On GitHub:

• Repo → Settings
• Secrets and variables → Actions
• Add secret:

⚠️ Never upload the public key here
⚠️ Never commit the private key

Step 4: Use it in GitHub Actions

Inside your workflow:

cat > ~/.ssh/deploy_key << 'KEY'
${{ secrets.EC2_SSH_KEY }}
KEY

chmod 600 ~/.ssh/deploy_key
ssh -i ~/.ssh/deploy_key logiccraft@SERVER_IP

GitHub can now deploy safely.

Security Summary (Why This Is Safe)

Each key has one responsibility.

Common Mistakes to Avoid

❌ Using the same key everywhere
❌ Uploading private keys to servers
❌ Adding CI keys as GitHub deploy keys
❌ Using root for deployments
❌ Using passphrases for CI keys

Recommended Production Setup

Server:
├── ~/.ssh/id_ed25519          → GitHub deploy key
├── ~/.ssh/authorized_keys     → CI/CD public key

GitHub:
├── Deploy Keys                → server public key
├── Secrets (Actions)          → CI private key

Clean. Secure. Scalable.

Final Thoughts

SSH is not hard — it’s context-sensitive.

Once you separate:

• who is connecting
• who must trust whom

Everything becomes obvious.

This setup is:

• production-ready
• secure
• industry standard
• easy to rotate or revoke

If you understand this distinction, you’ll never mix SSH keys again.