.. _Sichere Datenübertragung mit SSH und GPG: Sichere Datenübertragung mit ``ssh`` und ``gpg`` ================================================ Im folgenden Abschnitt sollen das Datenübertragungs-Protokoll SSH sowie die Dateiverschlüsselung GPG anhand von einigen praktischen Beispielen vorgestellt werden. .. index:: SSH .. _Arbeiten auf entfernten Rechnern: SSH -- Arbeiten auf entfernten Rechnern --------------------------------------- SSH steht für "Secure Shell" und ermöglicht sichere, verschlüsselte Netzwerkverbindungen mit anderen Computern. Um sich -- beispielsweise in einem Heim-Netzwerk -- wechselseitig auf einem entfernten Rechner einloggen zu können, sollten auf beiden Rechnern folgende Pakete installiert werden: .. code-block:: bash sudo aptitude install openssh-client openssh-server Hat man hingegen mehrere Clients, die unter einem jeweiligen Benutzernamen Zugriff auf einen Server haben sollen, so genügt es, bei diesen ``openssh-client`` und auf dem Server ``openssh-server`` zu installieren. Durch die Installation wird automatisch der SSH-Hintergrunddienst ``sshd`` gestartet; nach jedem Neustart des Rechners ist dieser ebenfalls aktiv. Um sich von einem Client aus in einem externen Rechner einzuloggen, kann man in einer Shell folgendes eingeben: .. code-block:: bash ssh benutzername@ip-adresse Die ``ip``-Adresse von Rechnern in einem lokalen Netzwerk erhält man beispielsweise, indem man in einer Shell beispielsweise ``nmap -sP 192.168.1.0/24`` oder (als Superuser) ``nast -m`` eingibt. .. TODO Fußnote: Allgemein nmap -sP 192.168.X.0/24 Existiert für den angegebenen Benutzername auf dem Rechner und wird das Passwort (des Benutzers auf dem externen Rechner) richtig eingegeben, so werden alle folgenden Anweisungen auf dem entfernten Rechner ausgeführt, nur die Bildschirmausgabe erfolgt lokal. Durch Eingabe von ``exit`` kann die SSH-Sitzung wieder verlassen werden. .. rubric:: ``scp und ssh -X`` Mittels ``scp`` kann via SSH eine einzelne Datei (oder ein einzelnes Verzeichnis) auf den entfernten Rechner kopiert werden. Die Syntax dafür lautet: .. code-block:: bash scp lokale-datei benutzername@ip-adresse:zielpfad Um mehrere Dateien auf einmal zu kopieren, können diese entweder mittels :ref:`tar ` gebündelt oder in ein Verzeichnis kopiert werden; mittels ``scp -r`` kann dieses Verzeichnis dann (wie eine einzelne Datei) rekursiv kopiert werden. Manche Dateimanager wie :ref:`mc ` nutzen ebenfalls intern ``scp``, um Dateien auf einfache Weise vom lokalen auf einen externen Rechner oder umgekehrt zu kopieren. Möchte man auf dem entfernten Rechner nicht nur Shell-Programme, sondern auch graphische Programme aufrufen, kann ``ssh`` mit der Option ``-X`` aufrufen werden, also mittels: .. code-block:: bash ssh -X benutzername@ip-adresse In diesem Fall bekommt man nach einer richtigen Passworteingabe ebenfalls ein Shell-Fenster angezeigt, kann in diesem allerdings auch graphische Programme aufrufen. .. _Anmeldung mit Public Key anstelle eines Passworts: Anmeldung mit Public Key anstelle eines Passworts ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Sicherer als Passwörter sind für die Authentifizierung eines Benutzers so genannte Schlüsselpaare: Ein privater Schlüssel auf dem eigenen PC, und ein öffentlicher Schlüssel, der an beliebig viele andere Stellen kopiert werden kann. Ein Login ist damit nur noch dann möglich, wenn der private und der öffentliche Schlüssel zusammenpassen. Ein Schlüsselpaar kann in einer Shell folgendermaßen erzeugt werden: .. code-block:: bash mkdir ~/.ssh ssh-keygen -t rsa Zu Übungszwecken kann bei der Nachfrage nach einem Passwort einfach ``Enter`` eingegeben werden; der private Schlüssel wird somit nicht mit einem Passwort versehen. Durch den Aufruf von ``ssh-keygen`` werden im Verzeichnis ``~/.ssh`` zwei Dateien angelegt: Die Datei ``id_rsa`` enthält den privaten Schlüssel, der nicht in falsche Hände geraten sollte, und die Datei ``id_rsa.pub`` ("public") den öffentlichen Schlüssel, der auf alle Rechner kopiert werden kann, auf denen man sich via SSH einloggen will. Zum Kopieren des öffentlichen Schlüssels kann folgendes in einer Schell eingegeben werden: .. code-block:: bash ssh-copy-id benutzername@ip-adresse Hierbei muss nochmals das Passwort des Benutzers auf dem Zielsystem eingegeben werden. Durch den Aufruf von ``ssh-copy-id`` wird der Standard-Schlüssel (oder durch Angabe von ``-i pfad`` eine explizit angegebene Schlüsseldatei) auf dem Zielrechner der Datei ``~/.ssh/authorized_keys`` hinzugefügt. Gibt man anschließend ``ssh benutzername@ip-adresse`` ein, so erfolgt das Einloggen via Schlüsselpaar anstelle der Eingabe eines Passworts. [#]_ Für ein wechselseitiges Verbinden zweier Rechner mittels SSH muss das oben beschriebene Verfahren auf beiden Rechnern erfolgen. .. _Aliases für häufige Login-Adressen: Aliases für häufige Login-Adressen ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ In der Datei ``~/.ssh/config`` können Kurzbezeichnungen für häufig besuchte externe Rechner vergeben werden. Um beispielsweise auf einen "Server" im Home-Netzwerk mit der lokalen Netzwerkadresse ``192.168.1.100`` zuzugreifen, fügt man der Datei ``~/.ssh/config`` folgenden Eintrag hinzu: .. code-block:: sh Host server HostName 192.168.1.100 User benutzername IdentityFile ~/.ssh/id_rsa Anschließend muss man nicht mehr ``ssh benutzername@192.168.1.100`` eingeben, um sich mit dem Server zu verbinden: Von nun an genügt es ``ssh server`` einzugeben. .. _Passwortschutz für private Schlüssel: Passwortschutz für private Schlüssel ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Gelangt der private Schlüssel an eine eigentlich unbefugte Person, so kann sich auch diese ebenso unmittelbar wie ungewollt auf dem Zielrechner einloggen. Um zu verhindern, dass der alleinige "Besitz" des privaten Schlüssels ausreicht, kann man diesen mit einem Passwort versehen; bevor er für das Einloggen verwendet werden kann, muss er erst mittels des Passworts freigegeben werden. Üblicherweise werden passwortgeschützte SSH-Schlüssel in Verbindung mit ``ssh-agent`` genutzt. Dieses Programm wird im Allgemeinen automatisch mit dem X-Server und/oder zu Begin einer Login-Shell gestartet und bleibt aktiv, bis sich der Benutzer wieder abmeldet. Beim der erstmaligen Verwendung des Schlüssels in einer laufenden Sitzung muss das Schlüssel-Passwort eingegeben werden; alle weiteren Zugriffe auf den Schlüssel sind anschließend erlaubt. [#]_ Ein passwortgeschützter Schlüssel, beispielsweise ``~/.ssh/id_rsa`` kann folgendermaßen zur Schlüsselverwaltung mittels ``ssh-agent`` hinzugefügt werden: .. code-block:: sh ssh-add ~/.ssh/id_rsa Wird ``ssh-agent`` ohne die explizite Angabe eines Schlüsselpfads gestartet, so werden automatisch alle im Verzeichnis ``~/.ssh`` liegenden Schlüssel hinzugefügt. Mittels ``ssh add -l`` können die von ``ssh-agent`` verwalteten Schlüssel angezeigt werden. .. index:: GPG .. _GnuPG: .. _Signieren von Dateien: .. _Verschlüsseln von Dateien: .. _Signieren und Verschlüsseln von Dateien: GPG -- Signieren und Verschlüsseln von Dateien ---------------------------------------------- GPG steht für "GNU Privacy Guard" und ist die wohl am weitesten verbreitete Implementierung von PGP ("Pretty Good Privacy"). Letzteres stellt einen Standard dar, mit dem u.a. Emails verschlüsselt verschickt werden können, sofern die Software sowohl beim Sender wie auch beim Empfänger installiert ist. GPG gehört bei fast allen Linux-Distributionen zum Standard, muss also nicht extra installiert werden. GPG nutzt -- ebenso wie SSH -- zum Verschlüsseln der Daten ein Schlüsselpaar: Der private Schlüssel bleibt auf dem eigenen Rechner und kann zum Entschlüsseln von Nachrichten verwendet werden; der öffentliche Schlüssel hingegen wird üblicherweise frei verteilt. Mit ihm können Nachrichten an den Eigentümer des Schlüssels verschlüsselt, jedoch nicht entschlüsselt werden. .. _Erstellen eines GPG-Schlüsselpaars: .. _Erstellen eines Schlüsselpaars: Erstellen eines GPG-Schlüsselpaars ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Zum Erstellen eines neuen Schlüsselpaars gibt man in einer Shell folgendes ein: .. code-block:: sh gpg --gen-key Hierbei wird man zunächst nach dem gewünschten Verschlüsselungsverfahren gefragt, wobei die Vorgabe "RSA und RSA" mit ``1`` ausgewählt werden kann. Als Schlüssellänge sollte man einen möglichst großen Wert nehmen -- 2048 Bit sind ok, 4096 Bit sind sicherer und somit besser. Als letztes muss man angeben, wie lange der Schlüssel gültig bleiben soll. Hier sollte durchaus eine Zeitvorgabe, beispielsweise ``1y`` für "1 Jahr" eingegeben werden, da Schlüssel ohne Verfallsdatum auch dann im Umlauf bleiben, wenn beispielsweise die zugehörige Emailadresse nicht mehr existiert oder die Schlüssellänge durch immer schnellere Rechner zu klein geworden ist. [#]_ Anschließend muss man als eindeutige Benutzerkennung noch den Namen und die Emailadresse angeben, zu dem der Schlüssel gehören soll. Das Passwort beziehungsweise, das man für den Schlüssel vergibt, sollte zwar gut merkbar, aber zugleich ausreichend sicher sein: * Das Passwort sollte nicht leicht zu erraten sein * Das Passwort darf Sonderzeichen beinhalten (muss es aber nicht) * Klein- und Großbuchstaben innerhalb des Passworts werden als unterschiedliche Buchstaben angesehen. * Lange Passwörter sind in der Regel sicherer als kurze, aber kryptische und damit schwer zu merkende Passwörter (siehe `xkcd `__). * Als Passwort kann auch ein ganzer Passwort-Satz (ein "Mantra") verwendet werden, da auch Leerzeichen im Passwort erlaubt sind. Ohne einen Passwortschutz des privaten Schlüssels könnte jede Person, die Zugriff auf die Schlüsseldatei bekommt, alle mit dem zugehörigen öffentlichen Schlüssel gesicherten Dateien öffnen. Zudem sollte der private Schlüssel nicht verloren gehen: Eine Sicherheits-Kopie des privaten Schlüssels auf eine externe :ref:`verschlüsselte Partition ` (beispielsweise eine USB-Stick oder eine externe Festplatte) ist dringend zu empfehlen! .. _Widerrufungs-Zertifikat: .. _Erstellen eines Widerrufungs-Zertifikats: .. rubric:: Erstellen eines Widerrufungs-Zertifikats Nachdem man ein Schlüsselpaar erzeugt hat, sollte man gleich im Anschluss daran eine Widerrufsurkunde erzeugen. Mit einer Widerrufsurkunde kann man seinen Schlüssel bei Bedarf als ungültig markieren. Ein solcher Fall kann beispielsweise eintreten, wenn man das Passwort vergessen hat oder der private Schlüssel aufgrund eines Festplatten-Defekts nicht mehr zugänglich ist. Mit einem als ungültig markierten Schlüssel können keine weiteren Emails mehr verschlüsselt oder signiert werden; bestehende Nachrichten hingegen können weiterhin entschlüsselt werden. Das Widerrufungs-Zertifikat ist vor allem von Bedeutung, wenn der öffentliche Schlüssel auf einen :ref:`Schlüssel-Server ` hochgeladen wurde: Diese synchronisieren in regelmäßigen Abständen ihre Datenbanken. Wird ein Schlüssel auf *einem* Server hinzugefügt, so ist er bald auch auf allen anderen Servern zu finden. Würde man seinen Schlüssel nur von einem der Schlüssel-Server löschen, so würde dieser sich nach der nächsten Synchronisation trotzdem wieder auf dem Server befinden. Anstelle einen Schlüssel zu löschen, setzt man daher ein Widerrufszertifikat ein. Um ein Widerrufungs-Zertifikat zu einem GPG-Schlüssel zu erzeugen, gibt man in einer Shell folgendes ein: .. code-block:: sh gpg --gen-revoke vorname.nachname@email.de Die Frage, ob man dieses Zertifikat wirklich erzeugen will, kann man mit ``Ja`` beantworten; als Grund für den Widerruf kann man beim voreingestellten Wert ``1`` ("Der Schlüssel ist nicht mehr sicher") bleiben. Optional kann noch ein Grund für den Widerruf eingegeben werden. Sobald man die Eingabe mit dem Passwort des GPG-Schlüssels bestätigt hat, kann man die auf dem Bildschirm erscheinende Ausgabe in eine Textdatei, beispielsweise ``Widerrufungszertifikat-SchluesselID.txt`` kopieren. Diese sollte -- ebenso wie den privaten GPG-Schlüssel -- auf einem externen Speichermedium sicher verwahren werden. .. _Schlüssel widerrufen: .. rubric:: Bei Bedarf: Widerrufen eines Schlüssels Möchte man einen eigenen Schlüssel tatsächlich widerrufen, so muss man ein zum Schlüssel gehörende Widerrufszertifikat importieren. Ein solcher Schritt muss allerdings gut überlegt sein, denn er kann nicht rückgängig gemacht werden. .. code-block:: sh gpg --import /pfad/Widerrufungszertifikat-SchluesselID.txt .. Alle Dokumente, Emails etc., die mit diesem Schlüssel verschlüsselt wurden, sind .. nicht wiederherstellbar. stimmt so vermutlich nicht?? Um das Widerrufen eines Schlüssels publik zu machen, sollte man den mit dem Widerrufungszertifikat versehenen Schlüssel erneut an einen Schlüsselserver senden. .. code-block:: sh gpg --send-keys Schlüssel-ID Ein so widerrufener Schlüssel kann nicht mehr genutzt werden, um Nachrichten oder andere Dateien zu verschlüsseln oder zu signieren. .. _Grundlegende GPG-Anweisungen: .. _Schlüsselbund verwalten: GPG-Schlüsselbund verwalten ^^^^^^^^^^^^^^^^^^^^^^^^^^^ Um mit GPG-Schlüsseln arbeiten zu können, wird bei der Erstellung eines Schlüsselpaares automatisch auch ein Schlüsselbund für private und ein Schlüsselbund für öffentliche Schlüssel erzeugt; diese werden im Verzeichnis ``~/.gnupg`` abgelegt. .. Im folgenden sind einige grundlegende Anweisungen näher beschrieben, die sich .. unmittelbar aus einer Shell heraus nutzen lassen, sobald ein GPG-Schlüsselpaar .. erzeugt wurde. .. Auch Email-Programme wie :ref:`mutt ` greifen auf diese Funktionen zurück. .. _Schlüssel auflisten: .. rubric:: Schlüssel auflisten Mit folgender Anweisung kann man alle öffentlichen Schlüssel auflisten, die im eigenen Schlüsselbund ("Public Key Ring") gespeichert sind: .. code-block:: sh # Öffentliche Schlüssel auflisten: gpg --list-keys .. Bei FCC5040F handelt es sich also um die Schlüssel-ID meines öffentlichen .. Schlüssels. 2004-04-26 ist das ISO-Datum (JJJJ-MM-TT) der Schlüsselerstellung. .. Die mit uid beginnenden Zeilen zeigen meine Benutzer-IDs ("user id"), wie z. B. .. Stephan Beyer . 1024 bedeutet, dass der Schlüssel 1024 Bit lang .. ist. Hinter der Länge steht jeweils das Verfahren: Ein D bedeutet DSA, g ist .. ElGamal, R steht für RSA. sub steht für öffentliche und ssb für geheime .. Unterschlüssel. .. Sollte hinter ``sec`` ein ``#``-Zeichen stehen, so bedeutet dies, dass der .. Schlüssel nicht mehr benutzbar ist . Arbeitet man das erste mal mit GPG, so enthält der Public-Key-Ring nur den eigenen öffentlichen Schlüssel. Im Laufe der Zeit kommen dann weitere Schlüssel von anderen Personen oder Einrichtungen hinzu, die ebenfalls GPG verwenden (beispielsweise wenn man einer solchen Person eine mit GPG verschlüsselte Email schreiben möchte). Alle öffentlichen Schlüssel sind in der Datei ``~/.gnupg/pubring.gpg`` abgelegt. private Schlüssel ("Secret Keys") werden hingegen in der Datei ``~/.gnupg/secring.gpg`` gespeichert. Sie können folgendermaßen angezeigt werden: .. code-block:: sh # Private Schlüssel auflisten: gpg --list-secret-keys .. _Schlüssel exportieren: .. rubric:: Schlüssel exportieren Möchte man, dass einem andere Personen eine verschlüsselte Email schreiben können, so müssen diese einen Zugang zum öffentlichen Schlüssel haben. Hierzu kann man den eigenen öffentlichen Schlüssel beispielsweise als Text-Datei auf einer Homepage veröffentlichen oder der jeweiligen Person per Email schicken. .. TODO oder, wie weiter unten beschrieben, auf einen Schlüsselserver hochladen. Um einen Schlüssel zu exportieren, kann man ``gpg`` mit der Option ``--export`` aufrufen. Hierbei werden allerdings standardmäßig *alle* Schlüssel ausgegeben. Möchte man nur den eigenen Schlüssel exportieren, so muss man die Auswahl dadurch einschränken, indem man hinter ``--export`` beispielsweise die zum Schlüssel gehörende Email-Adresse, den zum Schlüssel gehörenden Namen oder die ersten Stellen der Schlüssel-ID angibt: .. code-block:: sh # Eigenen Schlüssel exportieren: gpg -a -o ~/my-public-key.txt --export vorname.nachname@email.de Über die Option ``-o`` wird der Name der Datei festgelegt, in die der Schlüssel exportiert werden soll. Die Option ``-a`` als Kurzform für ``--armor`` bewirkt, dass der Schlüssel ausschließlich durch ASCII-Symbole dargestellt wird, so dass die resultierende Datei ohne Probleme auf eine Homepage hochgeladen oder als Anhang per Email verschickt werden kann (manchmal wird auch die Datei-Endung ``.asc`` oder ``.gpg`` anstelle von ``.txt`` verwendet). .. _Schlüssel importieren: .. rubric:: Schlüssel importieren Mit folgender Anweisung kann ein öffentlicher Schlüssel aus einer Textdatei importiert werden: .. code-block:: sh # Schlüssel aus Datei importieren: gpg --import schluesseldatei Die Schlüsseldatei muss hierbei mitsamt Endung (meist ``.txt``, ``.asc`` oder ``.gpg``) angegeben werden. Sobald ein Schlüssel zum eigenen Schlüsselbund hinzugefügt wurde, kann er verwendet werden, um beispielsweise der zugehörigen Person verschlüsselte Daten zu senden. Mittels ``gpg --delete-key`` kann man den öffentlichen Schlüssel mit der angegebenen ID wieder aus dem eigenen Schlüsselbund entfernen: .. code-block:: sh # Schlüssel aus Schlüsselbund entfernen: gpg --delete-key SchluesselID Mittels ``gpg --delete-secret-key ID`` kann man entsprechend einen privaten Schlüssel löschen. .. _Schlüssel-Attribute ändern: .. rubric:: Schlüssel-Attribute ändern Mittels folgender Anweisung lassen sich auch nachträglich Änderungen an einem GPG-Schlüssel vornehmen: .. code-block:: sh # Schlüssel-Attribute editieren: gpg --edit-key SchluesselID Nach Eingabe dieser Anweisung erscheint ein ``gpg>``-Eingabe-Prompt, in dem weitere GPG-Anweisungen aufgerufen werden können * Mit ``help`` bekommt man eine Liste aller möglichen Anweisungen mitsamt kurzen Beschreibungen angezeigt. * Mit ``expire`` kann man das Verfalls-Datum (``expire``) eines eigenen Schlüssels ändern * Mit ``passwd`` kann man das Passwort (Mantra) eines eigenen Schlüssels ändern Mit ``quit`` kann das Editieren wieder beendet werden. .. _Schlüssel-Server: .. _Nutzung von Schlüssel-Servern: .. rubric:: Nutzung von Schlüssel-Servern Eine weit verbreitete Methode, öffentliche GPG-Schlüssel publik zu machen, ist die Verwendung von so genannten Schlüssel-Servern. Man kann beispielsweise den (beziehungsweise einen) eigenen Schlüssel auf einen solchen Server hochladen, so dass er von anderen GPG-Nutzern in der ganzen Welt gefunden werden kann. Umgekehrt kann man so auch nach den GPG-Schlüsseln von anderen Personen suchen. Um einen Standard-Schlüssel-Server festzulegen, kann man in der Konfigurationsdatei ``~/.gnupg/gpg.conf`` beispielsweise folgenden Eintrag vornehmen:: # Eintrag in der Datei ~/.gnupg.conf : keyserver sks-keyservers.net Für die Nutzung von Schlüssel-Servern gibt es dann folgende ``gpg``-Anweisungen: * Mit ``gpg --search Name`` oder ``gpg --search emailadresse`` kann man nach öffentlichen Schlüsseln anderer Personen suchen. Sind Einträge vorhanden, so werden diese automatisch nummeriert aufgelistet. Man erhält daraufhin eine Abfrage, ob man einen der gefundenen Schlüssel durch Eingabe der zugehörigen Nummer in den eigenen Schlüsselbund importieren möchte, oder ob man die Eingabe mittels ``b`` beenden möchte. * Mit ``gpg --refresh`` werden alle öffentlichen Schlüssel aktualisiert. Auf diese Weise erhält man beispielsweise Informationen darüber, ob ein Schlüssel widerrufen wurde, andere Schlüssel-Signaturen hinzugekommen sind, usw. * Mit ``gpg --recv SchluesselID`` wird der öffentliche Schlüssel mit der angegebenen ID direkt importiert. Ist der angegebene Schlüssel bereits im Schlüsselbund enthalten, so wird der Schlüssel aktualisiert. * Mit ``gpg --send SchluesselID`` wird der öffentliche Schlüssel mit der angegebenen ID an den Schlüssel-Server geschickt; ``gpg`` gibt hierbei eine Fehler- oder Erfolgsmeldung auf dem Bildschirm aus. **Achtung:** Schlüssel, die einmal auf einen Schlüssel-Server hochgeladen wurden, können nie wieder gelöscht werden! Wie bereits im Abschnitt :ref:`Widerrufungs-Zertifikat ` erwähnt, gibt es keine Möglichkeit, einen Schlüssel wieder von einem Schlüssel-Server zu löschen. Schlüssel verlieren nur ihre Gültigkeit, wenn sie verfallen oder widerrufen werden; das Erstellen eines Widerrufungs-Zertifikats ist daher dringend zu empfehlen, bevor ein öffentlicher Schlüssel an andere weitergegeben wird -- schließlich kann *jeder* öffentliche Schlüssel auf einen Schlüssel-Server hochladen! .. _Signatur: .. _Daten signieren: Daten signieren ^^^^^^^^^^^^^^^ Signaturen sollen als "digitale Unterschriften" die Authentizität beispielsweise einer Nachricht beweisen. Würden Nachrichten von offizieller Seite konsequent signiert, wäre es deutlich schwerer, mit gefälschten Nachrichten Unruhe oder Schaden zu verursachen. Ein Signatur einer Nachricht wird unter Verwendung des privaten Schlüssels erzeugt; diese kann dann vom Empfänger anhand des öffentlichen Schlüssels des Senders überprüft werden. Dabei wird nicht nur der Absender überprüft (nur dieser hat den privaten Schlüssel), sondern auch, ob der Text unverändert angekommen ist. Eine Datei kann mit einer der folgenden Anweisungen signiert werden: * Mit ``gpg -s`` beziehungsweise ``gpg --sign`` kann man eine Datei mit seinem privaten Schlüssel signieren; sie wird dabei gleichzeitig komprimiert und ist somit nicht mehr ohne weiteres lesbar. * Mit ``gpg --clearsign`` kann man eine Datei signieren, wobei die Datei nicht komprimiert wird und somit lesbar bleibt. * Mit ``gpg -b`` beziehungsweise ``gpg --detach-sign`` wird die Signatur in einer separaten Datei abgelegt. Diese Variante ist beispielsweise zum Signieren von Archiv-Dateien empfehlenswert (diese können allerdings auch ohne Überprüfung der Signatur entpackt werden). Bei allen obigen Anweisungen kann die Option ``-a`` beziehungsweise ``--armor`` nützlich sein, um reine ASCII-Zeichen zu erzwingen; dies ist insbesondere beim Versenden von signierten und/oder verschlüsselten Daten via Email empfehlenswert. Die Signatur einer (unverschlüsselten) Datei kann man folgendermaßen prüfen: .. code-block:: sh # Signatur überprüfen: gpg --verify Datei Wurde die Datei von einer anderen Person signiert, so muss man zur Überprüfung der Signatur den öffentlichen Schlüssel dieser Person im eigenen Schlüsselbund haben. .. _Web of Trust: .. rubric:: Das "Web of Trust" Eine prinzipielle Schwachstelle der Public-Key-Methode ist die Verbreitung der öffentlichen Schlüssel: Ein Angreifer könnte einen öffentlichen Schlüssel mit einer falschen User-ID in Umlauf bringen. Wenn ein Sender diesen Schlüssel zur Verschlüsselung einer Nachricht verwendet und der Angreifer die Nachricht abfangen kann, so kann er diese dekodieren und lesen. Wenn der Angreifer die Nachricht anschließend mit einem echten öffentlichen Schlüssel kodiert an den eigentlichen Empfänger weiterleitet, fällt der Angriff unter Umständen nicht einmal auf. Derartige potentielle Angriffe, die auch bei anderen Verschlüsselungsverfahren möglich sind, nennt man daher "Man-in-the-Middle"-Angriffe. .. Vertrauen ist reflexiv, aber nicht symmetrisch oder transitiv. :-) Eine von von PGP beziehungsweise GnuPG gewählte Strategie gegen derartige Angriffe besteht im *Signieren der Schlüssel*: Jeder öffentliche Schlüssel kann von anderen Personen unterschrieben werden. Eine solche Unterschrift soll wiederum bestätigen, dass der Schlüssel authentisch ist, also zu der in der User-ID angegebenen Person gehört. Jeder Benutzer muss selbst entscheiden, welchen Unterschriften er wie weit traut. Man kann einen Schlüssel beispielsweise dann als vertrauenswürdig einstufen, wenn er von einer Person unterzeichnet wurde, der man vertraut. Ebenso sollte man selbst einen anderen Schlüssel nur dann unterzeichnen, wenn man die zum Schlüssel gehörende Person kennt und sich der Authentizität des Schlüssels auch wirklich sicher ist. .. _Daten verschlüsseln und entschlüsseln: Daten verschlüsseln und entschlüsseln ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Beim Verschlüsseln von Daten gibt es nun zwei Möglichkeiten: * Möchte man eine Datei mit dem eigenen privaten Schlüssel verschlüsseln (so dass man sie also nur selbst wieder entschlüsseln kann), so wird ohne weitere Vorgaben der Standard-Schlüssel verwendet; ebenso kann man mit der Option ``-u UserID`` gezielt einen Schlüssel auswählen. [#]_ * Möchte man eine Datei verschlüsselt an einen anderen Empfänger ("Recipient") schicken, so kann der Schlüssel dieses Empfängers mittels der Option ``-r UserID`` ausgewählt werden. Die eigentliche Anweisung zum Verschlüsseln einer Datei lautet: .. code-block:: sh # Datei verschlüsseln: gpg -e Empfaenger Datei Hierbei steht ``-e`` als Kurzform für die gleichbedeutende Option ``--encrypt``. Zusätzlich zu einer Verschlüsselung ist es stets sinnvoll, die Datei auch noch zu signieren. .. code-block:: sh # Datei verschlüsseln und signieren: gpg -u SenderID -r EmpfaengerID --armor --sign --encrypt Datei # Datei verschlüsseln und signieren (Kurzform): gpg -u SenderID -r EmpfaengerID -a -s -e Datei Das rekursive Verschlüsseln eines Verzeichnisses mitsamt Unterverzeichnissen ist nicht möglich; hierfür muss zunächst beispielsweise mittels :ref:`tar ` oder :ref:`zip ` eine Archiv-Datei des Verzeichnisses erstellt werden. .. Beispiel: .. ``tar -c /home/user/* | gpg -r Empfaenger -e -o /tmp/home.tar.crypt`` .. verschlüsselt alle Dateien des Verzeichnisses ``/home/user`` in die Datei .. ``/tmp/home.tar.crypt``. Folgende Anweisung stellt das Verzeichnis aus der .. verschlüsselten Datei wieder her: .. ``gpg -d /tmp/home.tar.crypt |tar -xvf -`` Wenn eine verschlüsselte Datei signiert ist, so wird beim Entschlüsseln die Signatur automatisch mitgeprüft. Die Anweisung zum Entschlüsseln einer Datei lautet: .. code-block:: sh # Datei entschlüsseln: gpg -d Datei Hierbei steht ``-d`` als Kurzform für die gleichbedeutende Option ``--decrypt``. Ohne weitere Vorgaben wird der Inhalt der Datei auf dem Standard-Ausgabe-Kanal ``stdout`` ausgegeben, üblicherweise also auf dem Bildschirm; mittels der Option ``-o Ausgabedatei`` wird die Ausgaben stattdessen in die angegebene Datei geschrieben. .. _Grenzen der Sicherheit: .. rubric:: Grenzen der Sicherheit Die von GPG verwendeten Algorithmen gelten allgemein bis heute als nicht knackbar; dies bedeutet jedoch nicht automatisch, dass alle mit GPG verschlüsselten Daten tatsächlich sicher sind. Bekommt beispielsweise ein professionaler Angreifer (beispielsweise über einen Trojaner) Zugriff auf einen privaten Schlüsselbund, der nur mit einem schlechten Passwort gesichert ist, so kann er dieses weitaus leichter knacken als die mit GPG verschlüsselten Daten selbst; mit dem privaten Schlüssel lassen sich die Daten allerdings regulär entschlüsseln. Für die Datensicherheit ist somit auch die allgemeine Systemsicherheit von Bedeutung. Wie "sicher" ein Verschlüsselungs-System sein muss, hängt letztlich vom konkreten Anwendungsfall ab: Möchte man "unkritische" private Daten nur vor einem einfachen Fremdzugriff schützen (ähnlich wie das bei Verwendung eines Kuverts bei einem Brief der Fall ist), so wird man sich wohl weniger Gedanken über Sicherheit machen als wenn man beispielsweise Server-Passwörter, Bank-Daten oder ähnlich sensible Daten verschlüsseln beziehungsweise vor Angreifern schützen möchte. Auch ohne Verschlüsselung ist der Einsatz von GPG sinnvoll, um beispielsweise bei Quellcode-Paketen die Integrität der jeweiligen Daten sicherzustellen (also ausschließen zu können, dass die jeweiligen Pakete nicht durch Dritte manipuliert wurden); nicht umsonst gehört ``gpg`` daher zum Standard-Umfang jeder Linux-Distribution. [#]_ .. Beim Verschlüsseln sollte man wissen, dass die verschlüsselten Dateien bzw. .. E-Mails wirklich nur der Empfänger entschlüsseln kann, also, wenn man dieser .. nicht ist, kann man sie auch selbst nicht mehr lesen (z. B. eine Kopie einer .. gesendeten verschlüsselten Mail wird lokal archiviert, und man will diese später .. wieder lesen). Um das zu ändern, ergänzt man encrypt-to eigeneID in der .. ~/.gnupg/gpg.conf. So wird zusätzlich der eigene öffentliche Schlüssel zum .. Verschlüsseln mitverwendet. Möchte man darauf in Ausnahmefällen wieder .. verzichten, so gibt man die Option --no-encrypt-to an. .. https://sks-keyservers.net/ .. rubric:: Links * `GPG Wikibook `__ * `GPG-Tutorial `__ * `GPG-Anleitung `__ * `GPG-Handbuch `__ .. raw:: html
.. only:: html .. rubric:: Anmerkungen: .. [#] Man kann in einem Heim-Netzwerk sogar, um die Sicherheit zu erhöhen, das Anmelden mittels Passworteingabe komplett verbieten. Dazu müssen (mit Superuser-Rechten) in der Datei ``/etc/ssh/sshd_config`` folgende Einträge vorgenommen werden: | ``PasswordAuthentication no`` | ``UsePAM no`` Damit können sich nur noch Benutzer einloggen, deren öffentliche Schlüssel in der jeweiligen Datei ``~/.ssh/authorized_keys`` stehen. In der gleichen Datei sollte zudem ein Login als Root unbedingt verboten werden: | ``PermitRootLogin no`` Gegebenenfalls kann ein :ref:`Benutzer mit Superuser-Rechten ` immer noch mit ``sudo`` systemweite Änderungen vornehmen oder sich mit ``sudo su root`` dauerhaft Superuser-Rechte verschaffen. .. TODO Restart des ssh-Dämons sshd... .. [#] Die Freigabe gilt auch für andere Programme, sofern diese in der laufenden Sitzung vom gleichen Benutzer gestartet wurden. .. [#] Die Gültigkeitsdauer eines Schlüssels kann jederzeit verlängert werden (siehe Abschnitt :ref:`Schlüssel-Attribute ändern `). .. [#] Hat man mehrere private Schlüssel, so kann man in der Konfigurationsdatei ``~/.gnupg/gpg.conf`` auch folgendermaßen einen Standard-Schlüssel festlegen: | ``# Eintrag in der Datei ~/.gnupg.conf :`` | ``default-key SchluesselID`` .. [#] Ein bekanntes Verfahren hierfür ist beispielsweise die so genannte "MD5-Prüfsumme": Nach diesem Verfahren wird zu der relevanten Datei zunächst über eine Hash-Funktion wie beispielsweise MD5 oder (besser) SHA-1 ein Hash-Wert berechnet (unter Linux gibt es dafür die Shell-Programme ``md5sum`` beziehungsweise ``sha1sum``; MD5 gilt ); dieser Hash-Wert wird anschließend vom Herausgeber mittels seines privaten Schlüssels signiert. Etwas vereinfacht kann man sich das so vorstellen, als würde man zu einer zehnstelligen Zahl die Quersumme ermitteln, also die Summe aller in der Zahl vorkommenden Ziffern zu berechnen. Das ist nicht wirklich schwer -- weitaus schwerer ist es hingegen, von dieser Quersumme auf die ursprüngliche Zahl zu schließen. Eine Hash-Funktion macht letztlich nichts anderes: Sie liefert zu einer bestimmten Dateneingabe stets einen eindeutigen Wert. Der Empfänger kann die Signatur wiederum mittels des öffentlichen Schlüssels des Herausgebers überprüfen. * Eine korrekte Signatur kann als Beweis dafür angesehen werden, dass der Hash-Wert tatsächlich vom Herausgeber stammt. * Anschließend kann geprüft werden, ob die Hash-Funktion bei Anwendung auf die heruntergeladene Datei einen identischen Hash-Wert erzeugt. Ist dies der Fall, so ist die Wahrscheinlichkeit sehr groß, dass die erhaltene Datei tatsächlich der Original-Datei entspricht. Inzwischen gilt `MD5 `__ nicht mehr als sicher; man sollte daher besser auf einen `SHA `__-Algorithmus zurückgreifen.