Git-Hostingdienste wie GitHub können mit der klassischen Authentifizierung bestehend aus Benutzername und Passwort genutzt werden. Wirklich bequem ist dies im Alltag jedoch nicht: Ständig ist die Eingabe des Passwortes erforderlich. Zwar ist es möglich, das Kennwort zu speichern:
git config --global credential.helper 'cache --timeout=86400'Git speichert dadurch das eingegebene Passwort für 24 Stunden. Dies reduziert die Passwortabfragen und kann theoretisch auch weiter erhöht werden. Allerdings gibt es einen gravierenden Nachteil: Das Passwort wird im Klartext in der Datei .gitconfig des Homeverzeichnisses gespeichert. Passwörter im Klartext zu speichern ist schlechte Praxis und sollte nach Möglichkeit vermieden werden.
SSH-Keys für Sicherheit und Komfort
Als wesentlich bessere Alternative bieten sich SSH-Schlüssel an. In der Linux-Welt kommen sie seit Jahrzehnten zum Einsatz, um verschlüsselt auf Linux-Systeme zugreifen zu können. Grundsätzlich wird ein Schlüsselpaar benötigt. Dies besteht aus einem privaten und öffentlichen Schlüssel. Mit dem öffentlichen Schlüssel lassen sich Daten verschlüsseln, die nur mithilfe des privaten Schlüssels wieder lesbar gemacht werden können. Es handelt sich um eine asymmetrische Verschlüsselung. Das Gegenstück ist die klassische symmetrische Verschlüsselung, bei der das gleiche Passwort zum Ver- und Entschlüsseln zur Anwendung kommt.
Der öffentliche Schlüssel wird auf das Zielsystem abgelegt. Damit kann dieses System Daten verschlüsseln, aber nicht entschlüsseln. Es ist daher auch völlig ungefährlich, den öffentlichen Key weiterzugeben. Beim privaten Schlüssel sieht dies allerdings ganz anders aus: Da er zur Entschlüsselung dient, sollte er das Gerät, auf dem er generiert wurde möglichst nicht verlassen.
Als Konsequenz gibt man private Schlüssel auch nicht dann weiter, wenn mehrere Benutzer Zugriff auf eine Ressource (z.B. einen Linux-Server) erhalten sollen. Stattdessen generiert jeder Benutzer sein eigenes Schlüsselpaar.
SSH ist jedoch nicht nur auf die Fernwartung von Linux-Systemen beschränkt. Es kann auch für Git genutzt werden. Das Prinzip bleibt gleich: Die Gegenstelle bekommt den öffentlichen Schlüssel, wodurch der private Schlüssel entsprechend zugriffsberechtigt wird. Zur Authentifizierung wird der private Schlüssel genutzt. Ein Passwort muss nicht eingegeben werden – außer man schützt den privaten Schlüssel zusätzlich mit einem Passwort (oft passphrase genannt).
Dies ist als zusätzlicher Schutz empfehlenswert – spätestens, wenn es sich um sensible Daten handelt. Ohne Schutz kann der private Schlüssel z.B. durch physischen Zugang zum Gerät kopiert werden. Der Angreifer besitzt dann die jeweiligen Rechte ohne zusätzlichen Schutz. Wurde dagegen ein Passwort vergeben, ist der Schlüssel ohne Kenntnis des Passwortes für den Angreifer nutzlos.
Schlüsselpaar generieren
Sofern noch kein Schlüsselpaar existiert, muss man zuerst eines generieren. Standardmäßig werden die Schlüssel im Heimverzeichnis des Benutzers in den versteckten Ordner .ssh gelegt und heißen id_rsa (privater Schlüssel) und id_rsa.pub. Das .pub steht für public, also öffentlich.
Im folgenden Beispiel existiert bereits ein Schlüsselpaar:
daniel@ws:~$ ls -lh ~/.ssh
insgesamt 8,0K
-rw------- 1 daniel daniel 1,7K Apr 17 14:38 id_rsa
-rw-r--r-- 1 daniel daniel 393 Apr 17 14:38 id_rsa.pub
Sollten keine Schlüssel vorliegen, können diese mit dem Kommandozeilenwerkzeug ssh-keygen in wenigen Sekunden erstellt werden. Man kann ihn auch ohne Parameter mit den Standardeinstellungen aufrufen. Ich setze die Länge immer auf das Maximum, um die Sicherheit zu erhöhen. Standardmäßig werden nur 2048 Bit lange Schlüssel erzeugt.
ssh-keygen -t rsa -b 4096Das Tool fragt nach dem Speicherort für den privaten und öffentlichen Schlüssel. Hier kann der oben beschrieben Standard mit der Enter-Taste übernommen werden. Optional lässt sich am Schluss ein zusätzliches Passwort festlegen, das den privaten Key schützt. Falls ihr des nicht möchtet, nichts eingeben und zweimal mit Enter bestätigen.
daniel@ws:~$ ssh-keygen -t rsa -b 4096
Generating public/private rsa key pair.
Enter file in which to save the key (/home/daniel/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/daniel/.ssh/id_rsa.
Your public key has been saved in /home/daniel/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:zQoWjC0vsMXvIYJ91c9I/oKKWa7jkrhVopF7J1+Oi4w daniel@ws
The key's randomart image is:
+---[RSA 4096]----+
| |
| . + . |
| . = = o |
| + + = + * |
|+ = = * S = |
| + = = + o |
|+.+ o + o . |
|+=.X = . |
|E+Bo*.. |
+----[SHA256]-----+Öffentlicher SSH-Schlüssel in GitHub hinterlegen
Nun muss der öffentliche Schlüssel mit dem eigenen GitHub-Account verknüpft werden. Dies berechtigt ihn zur Authentifizierung. Dazu öffnen wir in den Einstellungen die SSH-Key Seite und fügen einen neuen Schlüssel hinzu. Der Titel dient zur Identifikation. Den Schlüssel entnehmen wir aus der Datei ~/.ssh/id_rsa.pub, beispielsweise mit cat:
daniel@ws:~$ cat ~/.ssh/id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAA...Mit anderen gehosteten Git-Servern funktioniert es ähnlich. Bei Gogs beispielsweise klickt man auch rechts oben auf sein Profil, dann Ihre Einstellungen und links SSH-Schlüssel anklicken. Hier ebenfalls auf Schlüssel hinzufügen und den Key mit einer Bezeichnung angeben:
SSH-Agent aktivieren
Um den Schlüssel auf dem lokalen PC mit Git/GitHub nutzen zu können, wird der SSH-Agent benötigt. Diesen starten wir mit folgendem Befehl in der laufenden Shell:
daniel@ws:~$ eval "$(ssh-agent)"
Agent pid 27384Und fügen den erstellten Key hinzu:
daniel@ws:~$ ssh-add ~/.ssh/id_rsa
Identity added: /home/daniel/.ssh/id_rsa (/home/daniel/.ssh/id_rsa)Test: Auf die URL achten
Damit der soeben erstellte und authorisierte SSH-Schlüssel genutzt wird, müsst ihr beim Klonen die SSH-Adresse verwenden. Sie beginnt in der Regel mit git@ oder ssh:// wie im folgenden Beispiel:
Falls dort die https:// Adresse steht, könnt ihr oben auf Use SSH klicken. Wurde das Projekt bereits per HTTPS geklont, muss die als Remote hinterlegte URL geändert werden. Beispielsweise in .git/config:
[remote "origin"]
url = git@github.com:DMW007/FBMSCore.git
Unter Verwendung der korrekten URL ist keinerlei Login mehr notwendig. Ihr müsst maximal das Passwort des Keys eingeben, sofern dies gesetzt wurde.
daniel@ws:~$ git clone git@github.com:DMW007/FBMSCore.git
Klone nach 'FBMSCore' ...
The authenticity of host 'github.com (140.82.118.3)' can't be established.
RSA key fingerprint is SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'github.com,140.82.118.3' (RSA) to the list of known hosts.
remote: Enumerating objects: 1219, done.
remote: Counting objects: 100% (1219/1219), done.
remote: Compressing objects: 100% (733/733), done.
remote: Total 1219 (delta 389), reused 1207 (delta 377), pack-reused 0
Empfange Objekte: 100% (1219/1219), 1.94 MiB | 436.00 KiB/s, Fertig.
Löse Unterschiede auf: 100% (389/389), Fertig.