{"id":6741,"date":"2020-04-18T17:49:32","date_gmt":"2020-04-18T15:49:32","guid":{"rendered":"https:\/\/u-labs.de\/portal\/?p=6741"},"modified":"2020-04-18T17:49:34","modified_gmt":"2020-04-18T15:49:34","slug":"ssh-keys-zum-pullen-und-pushen-auf-git-servern-ohne-passwort-verwenden-am-beispiel-von-github","status":"publish","type":"post","link":"https:\/\/u-labs.de\/portal\/ssh-keys-zum-pullen-und-pushen-auf-git-servern-ohne-passwort-verwenden-am-beispiel-von-github\/","title":{"rendered":"SSH-Keys zum Pullen und Pushen auf Git-Servern ohne Passwort verwenden am Beispiel von GitHub"},"content":{"rendered":"

Git-Hostingdienste wie GitHub k\u00f6nnen mit der klassischen Authentifizierung bestehend aus Benutzername und Passwort genutzt werden. Wirklich bequem ist dies im Alltag jedoch nicht: St\u00e4ndig ist die Eingabe des Passwortes erforderlich. Zwar ist es m\u00f6glich, das Kennwort zu speichern: <\/p>\n

git config --global credential.helper 'cache --timeout=86400'<\/code><\/pre>\n
Git speichert dadurch das eingegebene Passwort f\u00fcr 24 Stunden. Dies reduziert die Passwortabfragen und kann theoretisch auch weiter erh\u00f6ht werden. Allerdings gibt es einen gravierenden Nachteil: Das Passwort wird im Klartext in der Datei .gitconfig<\/strong> des Homeverzeichnisses gespeichert. Passw\u00f6rter im Klartext zu speichern ist schlechte Praxis und sollte nach M\u00f6glichkeit vermieden werden.<\/p>\n
SSH-Keys f\u00fcr Sicherheit und Komfort<\/h2>\n
Als wesentlich bessere Alternative bieten sich SSH-Schl\u00fcssel<\/strong> an. In der Linux-Welt kommen sie seit Jahrzehnten zum Einsatz, um verschl\u00fcsselt auf Linux-Systeme zugreifen zu k\u00f6nnen. Grunds\u00e4tzlich wird ein Schl\u00fcsselpaar ben\u00f6tigt. Dies besteht aus einem privaten<\/strong> und \u00f6ffentlichen Schl\u00fcssel<\/strong>. Mit dem \u00f6ffentlichen Schl\u00fcssel lassen sich Daten verschl\u00fcsseln, die nur mithilfe des privaten Schl\u00fcssels wieder lesbar gemacht werden k\u00f6nnen. Es handelt sich um eine asymmetrische Verschl\u00fcsselung<\/strong>. Das Gegenst\u00fcck ist die klassische symmetrische Verschl\u00fcsselung<\/strong>, bei der das gleiche Passwort zum Ver- und Entschl\u00fcsseln zur Anwendung kommt.<\/p>\n
Der \u00f6ffentliche Schl\u00fcssel wird auf das Zielsystem abgelegt. Damit kann dieses System Daten verschl\u00fcsseln, aber nicht entschl\u00fcsseln. Es ist daher auch v\u00f6llig ungef\u00e4hrlich, den \u00f6ffentlichen Key weiterzugeben. Beim privaten Schl\u00fcssel sieht dies allerdings ganz anders aus: Da er zur Entschl\u00fcsselung dient, sollte er das Ger\u00e4t, auf dem er generiert wurde m\u00f6glichst nicht verlassen<\/strong>.<\/p>\n
Als Konsequenz gibt man private Schl\u00fcssel 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\u00fcsselpaar.<\/p>\n
SSH ist jedoch nicht nur auf die Fernwartung von Linux-Systemen beschr\u00e4nkt. Es kann auch f\u00fcr Git genutzt werden. Das Prinzip bleibt gleich: Die Gegenstelle bekommt den \u00f6ffentlichen Schl\u00fcssel, wodurch der private Schl\u00fcssel entsprechend zugriffsberechtigt wird. Zur Authentifizierung wird der private Schl\u00fcssel genutzt. Ein Passwort muss nicht eingegeben werden – au\u00dfer man sch\u00fctzt den privaten Schl\u00fcssel zus\u00e4tzlich mit einem Passwort (oft passphrase<\/strong> genannt).<\/p>\n
Dies ist als zus\u00e4tzlicher Schutz empfehlenswert – sp\u00e4testens, wenn es sich um sensible Daten handelt. Ohne Schutz kann der private Schl\u00fcssel z.B. durch physischen Zugang zum Ger\u00e4t kopiert werden. Der Angreifer besitzt dann die jeweiligen Rechte ohne zus\u00e4tzlichen Schutz. Wurde dagegen ein Passwort vergeben, ist der Schl\u00fcssel ohne Kenntnis des Passwortes f\u00fcr den Angreifer nutzlos.<\/p>\n
Schl\u00fcsselpaar generieren<\/h2>\n
Sofern noch kein Schl\u00fcsselpaar existiert, muss man zuerst eines generieren. Standardm\u00e4\u00dfig werden die Schl\u00fcssel im Heimverzeichnis des Benutzers in den versteckten Ordner .ssh<\/strong> gelegt und hei\u00dfen id_rsa<\/strong> (privater Schl\u00fcssel) und id_rsa.pub<\/strong>. Das .pub<\/strong> steht f\u00fcr public<\/strong>, also \u00f6ffentlich.<\/p>\n
Im folgenden Beispiel existiert bereits ein Schl\u00fcsselpaar:<\/p>\n
daniel@ws:~$ ls -lh ~\/.ssh\ninsgesamt 8,0K\n-rw------- 1 daniel daniel 1,7K Apr 17 14:38 id_rsa\n-rw-r--r-- 1 daniel daniel  393 Apr 17 14:38 id_rsa.pub\n<\/code><\/pre>\n
Sollten keine Schl\u00fcssel vorliegen, k\u00f6nnen diese mit dem Kommandozeilenwerkzeug ssh-keygen<\/strong> in wenigen Sekunden erstellt werden. Man kann ihn auch ohne Parameter mit den Standardeinstellungen aufrufen. Ich setze die L\u00e4nge immer auf das Maximum, um die Sicherheit zu erh\u00f6hen. Standardm\u00e4\u00dfig werden nur 2048 Bit lange Schl\u00fcssel erzeugt.<\/p>\n
ssh-keygen -t rsa -b 4096<\/code><\/pre>\n
Das Tool fragt nach dem Speicherort f\u00fcr den privaten und \u00f6ffentlichen Schl\u00fcssel. Hier kann der oben beschrieben Standard mit der Enter-Taste \u00fcbernommen werden. Optional l\u00e4sst sich am Schluss ein zus\u00e4tzliches Passwort festlegen, das den privaten Key sch\u00fctzt. Falls ihr des nicht m\u00f6chtet, nichts eingeben und zweimal mit Enter best\u00e4tigen.<\/p>\n
daniel@ws:~$ ssh-keygen -t rsa -b 4096\nGenerating public\/private rsa key pair.\nEnter file in which to save the key (\/home\/daniel\/.ssh\/id_rsa): \nEnter passphrase (empty for no passphrase): \nEnter same passphrase again: \nYour identification has been saved in \/home\/daniel\/.ssh\/id_rsa.\nYour public key has been saved in \/home\/daniel\/.ssh\/id_rsa.pub.\nThe key fingerprint is:\nSHA256:zQoWjC0vsMXvIYJ91c9I\/oKKWa7jkrhVopF7J1+Oi4w daniel@ws\nThe key's randomart image is:\n+---[RSA 4096]----+\n|                 |\n|   . + .         |\n|  . = = o        |\n| + + = + *       |\n|+ = = * S =      |\n| + = = + o       |\n|+.+ o + o .      |\n|+=.X =   .       |\n|E+Bo*..          |\n+----[SHA256]-----+<\/code><\/pre>\n
\u00d6ffentlicher SSH-Schl\u00fcssel in GitHub hinterlegen<\/h2>\n
Nun muss der \u00f6ffentliche Schl\u00fcssel mit dem eigenen GitHub-Account verkn\u00fcpft werden. Dies berechtigt ihn zur Authentifizierung. Dazu \u00f6ffnen wir in den Einstellungen die SSH-Key Seite<\/a> und f\u00fcgen einen neuen Schl\u00fcssel hinzu. Der Titel dient zur Identifikation. Den Schl\u00fcssel entnehmen wir aus der Datei ~\/.ssh\/id_rsa.pub<\/strong>, beispielsweise mit cat:<\/p>\n
daniel@ws:~$ cat ~\/.ssh\/id_rsa.pub \nssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAA...<\/code><\/pre>\n
Mit anderen gehosteten Git-Servern funktioniert es \u00e4hnlich. Bei Gogs beispielsweise klickt man auch rechts oben auf sein Profil, dann Ihre Einstellungen<\/strong> und links SSH-Schl\u00fcssel<\/strong> anklicken. Hier ebenfalls auf Schl\u00fcssel hinzuf\u00fcgen<\/strong> und den Key mit einer Bezeichnung angeben:<\/p>\n
\"\"<\/figure>\n
SSH-Agent aktivieren<\/h2>\n
Um den Schl\u00fcssel auf dem lokalen PC mit Git\/GitHub nutzen zu k\u00f6nnen, wird der SSH-Agent ben\u00f6tigt. Diesen starten wir mit folgendem Befehl in der laufenden Shell:<\/p>\n
daniel@ws:~$ eval "$(ssh-agent)"\nAgent pid 27384<\/code><\/pre>\n
Und f\u00fcgen den erstellten Key hinzu:<\/p>\n
daniel@ws:~$ ssh-add ~\/.ssh\/id_rsa\nIdentity added: \/home\/daniel\/.ssh\/id_rsa (\/home\/daniel\/.ssh\/id_rsa)<\/code><\/pre>\n
Test: Auf die URL achten<\/h2>\n
Damit der soeben erstellte und authorisierte SSH-Schl\u00fcssel genutzt wird, m\u00fcsst ihr beim Klonen die SSH-Adresse verwenden. Sie beginnt in der Regel mit git@<\/strong> oder ssh:\/\/<\/strong> wie im folgenden Beispiel:<\/p>\n
\"\"<\/figure>\n
Falls dort die https:\/\/ Adresse steht, k\u00f6nnt ihr oben auf Use SSH<\/strong> klicken. Wurde das Projekt bereits per HTTPS geklont, muss die als Remote hinterlegte URL ge\u00e4ndert werden. Beispielsweise in .git\/config<\/strong>:<\/p>\n
[remote "origin"]\n\turl = git@github.com:DMW007\/FBMSCore.git\n<\/code><\/pre>\n
Unter Verwendung der korrekten URL ist keinerlei Login mehr notwendig. Ihr m\u00fcsst maximal das Passwort des Keys eingeben, sofern dies gesetzt wurde.<\/p>\n
daniel@ws:~$ git clone git@github.com:DMW007\/FBMSCore.git\nKlone nach 'FBMSCore' ...\nThe authenticity of host 'github.com (140.82.118.3)' can't be established.\nRSA key fingerprint is SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8.\nAre you sure you want to continue connecting (yes\/no)? yes\nWarning: Permanently added 'github.com,140.82.118.3' (RSA) to the list of known hosts.\nremote: Enumerating objects: 1219, done.\nremote: Counting objects: 100% (1219\/1219), done.\nremote: Compressing objects: 100% (733\/733), done.\nremote: Total 1219 (delta 389), reused 1207 (delta 377), pack-reused 0\nEmpfange Objekte: 100% (1219\/1219), 1.94 MiB | 436.00 KiB\/s, Fertig.\nL\u00f6se Unterschiede auf: 100% (389\/389), Fertig.<\/code><\/pre>\n","protected":false},"excerpt":{"rendered":"
Git-Hostingdienste wie GitHub k\u00f6nnen mit der klassischen Authentifizierung bestehend aus Benutzername und Passwort genutzt werden. Wirklich bequem ist dies im Alltag jedoch nicht: St\u00e4ndig ist die Eingabe des Passwortes erforderlich. Zwar ist es m\u00f6glich, das Kennwort zu speichern: Git speichert dadurch das eingegebene Passwort f\u00fcr 24 Stunden. Dies reduziert die Passwortabfragen und kann theoretisch auch …<\/p>\n","protected":false},"author":5,"featured_media":6752,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[74,78],"tags":[613,804,781,803],"class_list":["post-6741","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-linux","category-software","tag-git","tag-github","tag-ssh","tag-ssh-keys"],"_links":{"self":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts\/6741","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/comments?post=6741"}],"version-history":[{"count":7,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts\/6741\/revisions"}],"predecessor-version":[{"id":6750,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts\/6741\/revisions\/6750"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/media\/6752"}],"wp:attachment":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/media?parent=6741"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/categories?post=6741"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/tags?post=6741"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}