Der direkte Weg, mehrere Hosts/Konten (Arbeits-GitHub, privates GitHub, externe Kunden) sauber mit ~/.ssh/config zu trennen.

Ein Arbeits-GitHub-Konto und ein privates GitHub-Konto auf demselben Gerät zu betreiben, läuft von Anfang an schief — git push landet beim falschen Konto, frisch geklonte Repos verweigern den Zugriff mit Permission denied, das gh-CLI meldet sich immer wieder beim selben Konto an. Dieser Leitfaden zeigt den direkten Weg, Konten und Hosts über ~/.ssh/config auf macOS 14+ / OpenSSH 9.x sauber zu trennen.

Eine Fortsetzung der Mac-Ersteinrichtung, wo du einen ed25519-Schlüssel erstellt hast. Erstreckt sich auch auf GitLab/Bitbucket für externe Kunden.

TL;DR

Für jedes Konto einen separaten SSH-Schlüssel (ed25519) mit eindeutigen Dateinamen erstellen
In ~/.ssh/config pro Host IdentityFile + Host-Aliase explizit setzen
Aliase in Klon-URLs verwenden: git@github-work:user/repo.git statt git@github.com:...
user.email per Arbeitsverzeichnis automatisch verzweigen mit .gitconfig includeIf
gh-CLI 1.x+ unterstützt mehrere gleichzeitige Konten

Voraussetzungen

macOS 14+, OpenSSH 9.x (ssh -V)
Ein GitHub/GitLab-Konto für jede Persona
Ein bestehendes Single-Key-Setup aus der Mac-Ersteinrichtung oder äquivalent

1. Pro-Konto SSH-Schlüssel — 5 Min.

Absichtlich eindeutige Dateinamen verwenden.

# Arbeitskonto
ssh-keygen -t ed25519 -C "work@example.com" -f ~/.ssh/id_ed25519_work
 
# Privatkonto
ssh-keygen -t ed25519 -C "personal@example.com" -f ~/.ssh/id_ed25519_personal
 
# Externer Kunde (optional)
ssh-keygen -t ed25519 -C "client-foo@example.com" -f ~/.ssh/id_ed25519_client

Nur den öffentlichen Schlüssel (.pub) bei jedem GitHub/GitLab-Konto registrieren:

pbcopy < ~/.ssh/id_ed25519_work.pub       # Arbeits-GitHub
pbcopy < ~/.ssh/id_ed25519_personal.pub   # privates GitHub

Im Browser https://github.com/settings/ssh/new aufrufen, als jedes Konto anmelden, einfügen, speichern.

GitHub lehnt die Wiederverwendung desselben Schlüssels für zwei Konten ab. Daher ist die Pro-Konto-Schlüsseltrennung Pflicht.

2. `~/.ssh/config` erstellen — 10 Min.

Mit Host-Aliasen aufteilen. Nahtlos integriert mit macOS-Schlüsselbund und Touch ID.

# ~/.ssh/config
 
# Arbeits-GitHub
Host github-work
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_work
  IdentitiesOnly yes
  AddKeysToAgent yes
  UseKeychain yes
 
# Privates GitHub
Host github-personal
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_personal
  IdentitiesOnly yes
  AddKeysToAgent yes
  UseKeychain yes
 
# Kunden-GitLab
Host gitlab-client
  HostName gitlab.com
  User git
  IdentityFile ~/.ssh/id_ed25519_client
  IdentitiesOnly yes
  AddKeysToAgent yes
  UseKeychain yes

Schlüssel-Optionen:

IdentitiesOnly yes — auch wenn der Agent weitere Schlüssel hält, wird ausschließlich der explizit angegebene verwendet. Fehlt diese Option, wird der falsche Schlüssel zuerst versucht und GitHub antwortet mit 403.
AddKeysToAgent yes + UseKeychain yes — macOS-Schlüsselbund-Integration. Passphrase einmal eingeben, danach nie wieder.

Schlüssel zum SSH-Agent hinzufügen

ssh-add --apple-use-keychain ~/.ssh/id_ed25519_work
ssh-add --apple-use-keychain ~/.ssh/id_ed25519_personal
ssh-add --apple-use-keychain ~/.ssh/id_ed25519_client

Verifizierung

ssh -T git@github-work
# Hi work-username! You've successfully authenticated...
 
ssh -T git@github-personal
# Hi personal-username! You've successfully authenticated...

Wird das falsche Konto gemeldet, siehe §3 / Problembehandlung.

3. Aliase in Klon-URLs verwenden — das tägliche Muster

Arbeits-Repo:

# Normale GitHub-URL — IdentitiesOnly wählt noch den richtigen Schlüssel, aber expliziter Alias ist sauberer
git clone git@github.com:org/repo.git  # IdentitiesOnly + erster Treffer — mehrdeutig
 
# Alias verwenden — explizit
git clone git@github-work:org/repo.git

Privates Repo:

git clone git@github-personal:me/myrepo.git

Bereits geklonte Repos: Remote ändern.

cd ~/work/repo
git remote set-url origin git@github-work:org/repo.git
 
cd ~/personal/myrepo
git remote set-url origin git@github-personal:me/myrepo.git

Mit git remote -v verifizieren.

4. `user.email` automatisch verzweigen — `includeIf` — 5 Min.

git config user.email nach Verzeichnis-Standort verzweigen. Commits in Arbeitsverzeichnissen verwenden automatisch die Arbeits-E-Mail, persönliche Ordner die persönliche E-Mail.

Haupt-`~/.gitconfig`

[user]
  name = Your Name
  # Standard-E-Mail leer lassen oder häufigste verwenden
 
[includeIf "gitdir:~/work/"]
  path = ~/.gitconfig-work
 
[includeIf "gitdir:~/personal/"]
  path = ~/.gitconfig-personal

⚠️ Der Pfad nach gitdir: muss mit einem Schrägstrich enden. ~/work ist falsch, ~/work/ ist richtig.

`~/.gitconfig-work`

[user]
  email = you@company.com
  name = Your Name (Company)
 
[commit]
  gpgsign = true   # wenn Unternehmensrichtlinie signierte Commits erfordert
 
[gpg]
  format = ssh
 
[gpg "ssh"]
  defaultKeyCommand = ssh-add -L
  program = ssh-keygen

`~/.gitconfig-personal`

[user]
  email = you@personal.com
  name = Your Name

Verifizierung

cd ~/work/some-repo
git config user.email
# you@company.com
 
cd ~/personal/some-repo
git config user.email
# you@personal.com

Das automatische Routing funktioniert. So werden Commits mit der falschen E-Mail strukturell verhindert.

5. `gh`-CLI Multi-Konto — gleichzeitige Auth

gh 2.40+ unterstützt Multi-Konto. Du kannst gleichzeitig bei Arbeits- und privatem GitHub.com vom selben Gerät aus angemeldet sein.

Auth hinzufügen

# Erstes Konto (überspringen wenn bereits angemeldet)
gh auth login
 
# Zweites Konto
gh auth login    # als anderes GitHub.com-Konto anmelden

Aktives Konto wechseln

gh auth status
# Listet alle angemeldeten Konten und das aktive auf
 
gh auth switch
# Interaktiv — anderes Konto auswählen
 
gh auth switch -u personal-username

Pro-Repo aktives Konto (optional)

# In einem Arbeits-Repo das Arbeitskonto aktivieren
cd ~/work/repo
gh auth switch -u work-username

gh-Befehle verwenden das aktive Konto. SSH wird durch die Konfiguration in §2 gesteuert — kein Konflikt.

6. Häufige Problempunkte

6.1 Personal Access Token (PAT)-Konflikte

Wenn du bei gh auth login HTTPS gewählt hast, wird der PAT im OS-Schlüsselbund gespeichert. Falscher PAT wird für andere Konten verwendet:

gh auth status                    # welcher PAT wo gespeichert ist
security find-internet-password -s github.com -a "your-username"
security delete-internet-password -s github.com -a "wrong-username"
gh auth login                      # erneut authentifizieren

6.2 Dieselbe Organisation von beiden Konten aus zugegriffen

Wenn dein privates Konto auch Mitarbeiter der Arbeits-GitHub-Org ist, werden Klon-URLs mehrdeutig:

# Explizite Aliase verwenden
git clone git@github-work:org/shared-repo.git work-side
git clone git@github-personal:org/shared-repo.git personal-side

Sie in separaten Verzeichnissen ablegen, trennt user.email + Schlüsselauswahl.

6.3 macOS-Schlüsselbund vergisst Passphrase

UseKeychain yes in ~/.ssh/config wird bei einigen macOS 15+-Setups ignoriert. Workaround:

# SSH-Agent explizit starten + Schlüssel hinzufügen
eval "$(ssh-agent -s)"
ssh-add --apple-use-keychain ~/.ssh/id_ed25519_work

Das Auto-Register-Snippet kann bei Bedarf zu .zshrc hinzugefügt werden.

7. Sicherheits-Checkliste

Private Schlüssel niemals teilen — nur .pub wird registriert
Passphrase verwenden — verschlüsselt die Schlüsseldatei. macOS-Schlüsselbund cacht nach einem Eintrag
Arbeits-/Private-Schlüssel trennen — begrenzt den Blast-Radius, wenn einer durchsickert
~/.ssh/config-Berechtigungen — chmod 600 ~/.ssh/config
~/.ssh-Verzeichnisberechtigungen — chmod 700 ~/.ssh
Hardware-Schlüssel (optional) — YubiKey + FIDO2 über ssh-keygen -t ed25519-sk (separater Leitfaden)

8. Problembehandlung

`Permission denied (publickey)` trotz explizitem Schlüssel

IdentitiesOnly yes fehlt — die anderen Schlüssel des Agents werden zuerst versucht und abgelehnt. Zur Konfig hinzufügen.

ssh -vT git@github-work 2>&1 | grep -E "(Offering|identity file)"

Wenn mehrere Schlüssel versucht werden, fehlt IdentitiesOnly yes.

Als falsches Konto begrüßt

ssh -T git@github-work gibt das private Konto zurück. Ursachen:

Falscher Schlüssel im ssh-Agent priorisiert
Blockreihenfolge oder Tippfehler im Host github-work / IdentityFile von ~/.ssh/config

ssh-add -L                          # welche Schlüssel im Agent sind
ssh-add -D                          # alle löschen
ssh-add --apple-use-keychain ~/.ssh/id_ed25519_work
ssh -T git@github-work

`git push` geht zum privaten Konto

URL ist git@github.com:org/repo.git und der private Schlüssel gewinnt im Agent. URL ändern.

git remote set-url origin git@github-work:org/repo.git

`includeIf` wird nicht ausgelöst

Abschließender Schrägstrich im Pfad fehlt (~/work ❌, ~/work/ ✅)
Ordner ist ein Symlink — OS-abhängig. Echten Pfad verwenden.

`gh auth switch` nicht verfügbar

gh ist älter als 2.40. Upgrade:

brew upgrade gh
gh --version

Mehrere GitHub-Konten per SSH auf dem Mac — Arbeit + private Schlüssel verwalten

TL;DR

Voraussetzungen

1. Pro-Konto SSH-Schlüssel — 5 Min.

2. `~/.ssh/config` erstellen — 10 Min.

Schlüssel zum SSH-Agent hinzufügen

Verifizierung

3. Aliase in Klon-URLs verwenden — das tägliche Muster

4. `user.email` automatisch verzweigen — `includeIf` — 5 Min.

Haupt-`~/.gitconfig`

`~/.gitconfig-work`

`~/.gitconfig-personal`

Verifizierung

5. `gh`-CLI Multi-Konto — gleichzeitige Auth

Auth hinzufügen

Aktives Konto wechseln

Pro-Repo aktives Konto (optional)

6. Häufige Problempunkte

6.1 Personal Access Token (PAT)-Konflikte

6.2 Dieselbe Organisation von beiden Konten aus zugegriffen

6.3 macOS-Schlüsselbund vergisst Passphrase

7. Sicherheits-Checkliste

8. Problembehandlung

`Permission denied (publickey)` trotz explizitem Schlüssel

Als falsches Konto begrüßt

`git push` geht zum privaten Konto

`includeIf` wird nicht ausgelöst

`gh auth switch` nicht verfügbar

Nächste Schritte

Referenzen

Changelog

Mehrere GitHub-Konten per SSH auf dem Mac — Arbeit + private Schlüssel verwalten

TL;DR

Voraussetzungen

1. Pro-Konto SSH-Schlüssel — 5 Min.

2. ~/.ssh/config erstellen — 10 Min.

Schlüssel zum SSH-Agent hinzufügen

Verifizierung

3. Aliase in Klon-URLs verwenden — das tägliche Muster

4. user.email automatisch verzweigen — includeIf — 5 Min.

Haupt-~/.gitconfig

~/.gitconfig-work

~/.gitconfig-personal

Verifizierung

5. gh-CLI Multi-Konto — gleichzeitige Auth

Auth hinzufügen

Aktives Konto wechseln

Pro-Repo aktives Konto (optional)

6. Häufige Problempunkte

6.1 Personal Access Token (PAT)-Konflikte

6.2 Dieselbe Organisation von beiden Konten aus zugegriffen

6.3 macOS-Schlüsselbund vergisst Passphrase

7. Sicherheits-Checkliste

8. Problembehandlung

Permission denied (publickey) trotz explizitem Schlüssel

Als falsches Konto begrüßt

git push geht zum privaten Konto

includeIf wird nicht ausgelöst

gh auth switch nicht verfügbar

Nächste Schritte

Referenzen

Changelog

2. `~/.ssh/config` erstellen — 10 Min.

4. `user.email` automatisch verzweigen — `includeIf` — 5 Min.

Haupt-`~/.gitconfig`

`~/.gitconfig-work`

`~/.gitconfig-personal`

5. `gh`-CLI Multi-Konto — gleichzeitige Auth

`Permission denied (publickey)` trotz explizitem Schlüssel

`git push` geht zum privaten Konto

`includeIf` wird nicht ausgelöst

`gh auth switch` nicht verfügbar