So verwalten Sie mehrere SSH-Schlüssel

Man kann mit Sicherheit sagen, dass die meisten Entwickler im Webbereich irgendwann auf SSH gestoßen sind. SSH ist eines der am häufigsten verwendeten Protokolle für den sicheren Datenaustausch. Sie verwenden SSH für die Verbindung zu Remote-Servern. Dazu gehört auch die Verwaltung Ihres Codes mithilfe von Git und die Synchronisierung mit Remote-Repositorys.

Obwohl es als gute Praxis angesehen wird, ein privat-öffentliches Schlüsselpaar pro Gerät zu haben, müssen Sie manchmal mehrere Schlüssel verwenden und / oder Sie haben unorthodoxe Schlüsselnamen.

Möglicherweise verwenden Sie ein SSH-Schlüsselpaar für die Arbeit an internen Projekten Ihres Unternehmens, aber Sie verwenden möglicherweise einen anderen Schlüssel für den Zugriff auf die Server einiger Unternehmensclients. Möglicherweise verwenden Sie sogar einen anderen Schlüssel für den Zugriff auf Ihren eigenen privaten Server.

Das Verwalten von SSH-Schlüsseln kann umständlich werden, sobald Sie einen zweiten Schlüssel verwenden müssen. Ich hoffe, dieser Artikel hilft allen, die Probleme mit der Verwaltung von SSH-Schlüsseln haben.

Ich gehe davon aus, dass der Leser Grundkenntnisse in Git und SSH hat. Die meisten Beispiele im gesamten Artikel verwenden Git. All dies gilt natürlich auch für jede andere SSH-Kommunikation. Davon abgesehen sind einige Git-spezifische Tricks enthalten.

Schnall dich an, los geht's!

Umgang mit einem SSH-Schlüssel

Lassen Sie uns zunächst sehen, wie Ihr Workflow aussehen könnte, bevor Sie sich um mehrere Schlüssel kümmern müssen.

Sie haben einen privaten Schlüssel ~/.ssh/id_rsamit einem entsprechenden öffentlichen Schlüssel gespeichert ~/.ssh/id_rsa.pub.

Stellen wir uns vor, Sie möchten Codeänderungen auf einen / von einem entfernten Git-Server übertragen / ziehen - sagen Sie GitHub, warum nicht. Dazu müssen Sie zuerst Ihren öffentlichen Schlüssel zu GitHub hinzufügen.

Ich werde diesen Schritt nicht durchgehen, es sollte leicht genug sein, herauszufinden, wie das geht. Ich habe auch angenommen, dass Sie Steve heißen und an einem streng geheimen Projekt arbeiten, bei dem Raspberry Pies zum Aufspüren des Netzwerkverkehrs verwendet werden.

Um Ihre Arbeit zu beginnen, müssen Sie ein Git-Repository mit SSH klonen:

git clone [email protected]:steve/raspberry-spy.git

In diesem Moment wird GitHub folgendermaßen aussehen: „Yo, das ist ein privates Repository! Wir müssen den Datenverkehr mit diesem öffentlichen Schlüssel, den ich hier habe, und Ihrem privaten Schlüssel verschlüsseln. “

Sie haben den öffentlichen Schlüssel zu Ihrem Profil auf GitHub hinzugefügt, aber SSH muss irgendwie herausfinden, wo sich Ihr entsprechender privater Schlüssel befindet.

Da wir keine Ahnung haben, welcher private Schlüssel beim SSH-Eingriff verwendet werden soll [email protected], versucht der SSH-Client, einen Schlüssel am Standardspeicherort zu finden. Dies ist ~/.ssh/id_rsaseine beste Vermutung. Wenn sich an diesem Speicherort keine Datei befindet, wird eine Fehlermeldung angezeigt:

Cloning into 'raspberry-spy'... Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists.

Wenn Sie einige private Schlüssel in der Datei gespeichert sind ~/.ssh/id_rsa, wird SSH - Client, der private Schlüssel für die Kommunikation Verschlüsselung verwenden. Wenn dieser Schlüssel mit einem Passwort versehen ist (wie es sein sollte), werden Sie wie folgt zur Eingabe eines Passworts aufgefordert:

Enter passphrase for key '/Users/steve/.ssh/id_rsa':

Wenn Sie die richtige Passphrase eingeben und dieser private Schlüssel tatsächlich dem öffentlichen Schlüssel entspricht, den Sie an Ihr Profil angehängt haben, funktioniert alles einwandfrei und das Repository wird erfolgreich geklont.

Aber was ist, wenn Sie Ihren Schlüssel anders benannt haben (z. B. ~/.ssh/_id_rsa)? Der SSH-Client kann nicht feststellen, wo der private Schlüssel gespeichert ist. Sie erhalten den gleichen Permission denied ...Fehler wie zuvor.

Wenn Sie einen privaten Schlüssel verwenden möchten, den Sie anders benannt haben, müssen Sie ihn manuell hinzufügen:

ssh-add ~/.ssh/_id_rsa

Nach Eingabe der Passphrase können Sie ssh-agentdurch Ausführen überprüfen, ob der Schlüssel zu (SSH-Client) hinzugefügt wurde ssh-add -l. Dieser Befehl listet alle Schlüssel auf, die derzeit für den SSH-Client verfügbar sind.

Wenn Sie jetzt versuchen, das Repository zu klonen, ist dies erfolgreich.

So weit, ist es gut?

Wenn Sie scharfe Augen haben, werden Sie möglicherweise einige potenzielle Probleme bemerken.

Erstens, wenn Sie Ihren Computer ssh-agentneu starten, wird neu gestartet und Sie müssen Ihre nicht standardmäßig benannten Schlüssel ssh-adderneut hinzufügen , indem Sie Kennwörter und all das mühsame Zeug eingeben.

Können wir das Hinzufügen von Schlüsseln automatisieren oder irgendwie angeben, welcher Schlüssel beim Zugriff auf bestimmte Server verwendet werden soll?

Können wir Passwörter irgendwie speichern, damit wir sie nicht jedes Mal eingeben müssen? Wenn es nur so etwas wie einen Schlüsselbund zum Speichern passwortgeschützter SSH-Schlüssel gäbe ?

Seien Sie versichert, es gibt Antworten auf all diese Fragen.

Geben Sie ein, SSH config

Wie sich herausstellt, ist die SSH-Konfigurationsdatei eine Sache, die uns helfen kann. Es ist eine Benutzerkonfigurationsdatei für die SSH-Kommunikation. Erstellen Sie eine neue Datei: ~/.ssh/configund öffnen Sie sie zur Bearbeitung.

Verwalten von benutzerdefinierten SSH-Schlüsseln

Das erste, was wir mit dieser configDatei lösen werden , ist zu vermeiden, dass Sie benutzerdefinierte SSH-Schlüssel mit hinzufügen müssen ssh-add. Angenommen, Ihr SSH-Schlüssel heißt benannt ~/.ssh/_id_rsa, fügen Sie der configDatei Folgendes hinzu :

Host github.com HostName github.com User git IdentityFile ~/.ssh/_id_rsa IdentitiesOnly yes

Stellen Sie nun sicher, dass dies ~/.ssh/_id_rsanicht ssh-agentder Fall ist, indem Sie ausführen ssh-add -D. Dieser Befehl entfernt alle Schlüssel aus der aktuell aktiven ssh-agentSitzung. Die Sitzung wird jedes Mal zurückgesetzt, wenn Sie sich abmelden oder neu starten (oder wenn Sie den ssh-agentProzess manuell beenden). Wir können einen Neustart „simulieren“, indem wir den genannten Befehl ausführen.

If you try cloning your GitHub repository now, it will be the same as if we added the key manually (like we did before). You will be asked for password:

git clone [email protected]:steve/raspberry-spy.git Cloning into 'raspberry-spy'... Enter passphrase for key '/Users/steve/.ssh/_id_rsa':

You will have noticed that the key for whose password we are prompted for is the same key which we specified in our config file. After entering the correct SSH key password, repository will be successfully cloned.

Note: if, after successful cloning, you try git pull, you will be prompted for password again. We will solve that later.

It is important that Host github.com from config and github.com from URI [email protected]:steve/raspberry-spy.git match. You can also change config to be Host mygithub and clone using URI [email protected]:steve/raspberry-spy.git.

This opens the floodgates. As you are reding this, your mind is racing and thinking about how all your troubles with SSH keys are over. Here are some useful configuration examples:

Host bitbucket-corporate HostName bitbucket.org User git IdentityFile ~/.ssh/id_rsa_corp IdentitiesOnly yes

Now you can use git clone [email protected]:company/project.git

Host bitbucket-personal HostName bitbucket.org User git IdentityFile ~/.ssh/id_rsa_personal IdentitiesOnly yes

Now you can use git clone [email protected]:steve/other-pi-project.git

Host myserver HostName ssh.steve.com Port 1111 IdentityFile ~/.ssh/id_rsa_personal IdentitiesOnly yes User steve IdentitiesOnly yes

Now you can SSH into your server using ssh myserver. How cool is that? You do not need to enter port and username manually every time you execute ssh command.

Bonus: Per-repository settings

You can also define which specific key should be used for certain repository, overriding anything in SSH config. Specific SSH command can be defined by setting sshCommand under core in /.git/config. Example:

[core] sshCommand = ssh -i ~/.ssh/id_rsa_corp

This is possible with git 2.10 or later. You can also use this command to avoid editing the file manually:

git config core.sshCommand 'ssh -i ~/.ssh/id_rsa_corp'

Password managemet

Last piece of the puzzle is managing passwords. We want to avoid having to enter password every time when SSH connection is initiating. To do so, we can utilize keychain management software that comes with MacOS and various Linux distributions.

Start by adding your key to the keychain by passing -K option to the ssh-add command:

ssh-add -K ~/.ssh/id_rsa_whatever

Now you can see your SSH key in the keychain. On MacOS it looks something like this:

Keychain Access

If you remove the keys from ssh-agent via ssh-add -D (this will happen when you restart your computer, as mentioned before) and try SSH-ing, you will be prompted for password again. Why? We just added the the key to the keychain. If you check Keychain Access again, you will notice that the key you added using ssh-add -K is still in the keychain. Weird, huh?

It turns out there is one more hoop to jump through. Open your SSH config file and add the following:

Host * AddKeysToAgent yes UseKeychain yes

Now, SSH will look for key in keychain and if it finds it you will not be prompted for password. Key will also be added to ssh-agent. On MacOS this will work on MacOS Sierra 10.12.2 or later. On Linux you can use something like gnome-keyring and it might work even without this last modification to SSH config. As for Windows - who knows, right?

I hope someone found this useful. Now go and configure your SSH config file!

Learn more about SSH:

  • The ultimate guide to SSH keys
  • A top-down introduction to SSH