Public & Private Key

Öffentliche und private Schlüssel sind Schlüsselpaare, die in der Public-Key-Kryptographie verwendet werden. Der öffentliche Schlüssel (PubKey) kann frei verteilt werden und dient dazu, Nachrichten zu verschlüsseln oder digitale Signaturen zu verifizieren. Der private Schlüssel (PrivKey) muss geheim gehalten werden und dient zum Entschlüsseln dieser Nachrichten und zum Erstellen eigener digitaler Signaturen. 

RSA (stark verbreitet) gilt ab einer Schlüsselellänge von mindestens 3072 Bit als sicher und ECDSA (Elliptic Curve Digital Signature Algorithm) sowie ED25519 (moderne Alternative für SSH und digitale Signaturen) mit besonders guter Sicherheit und Performance sind die aktuellsten mathematischen Techniken. Die mathematische Basis dieser Algorithmen sind sogenannte Einweg- und Falltürfunktionen. Diese sind leicht in eine Richtung berechenbar, aber nur mit dem privaten Schlüssel in die andere Richtung lösbar – das ist die „Falltür“.

Anwendungen sind sichere SSH-Verbindungen für Server und SFTP, E-Mail-Verschlüsselung und -Signatur (PGP, S/MIME), SSL/TLS für sichere Webseiten und digitale Signaturen und Zertifikate.

In diese Beitrag beschäftige ich mich nun weiter mit SSH-Verbindungen zwischen Rechnern.

Schlüsselpaar erstellen

Meine Best Practices ist ein asymmetrisches Schlüsselpaar möglichst auf vertrauenswürdigen (idealerweise offline) Systemen zu generieren und dort an sicherer Stelle – u.a. im versteckten lokalen Ordner unter dem eigenen Benutzerkonto zum Beispiel im Ordner .ssl zu speichern und weiter zu schützen.

Als Generator nutze ich zB auf meinem MacBook in der Konsole (Terminal) folgenden Befehl

ssh-keygen -t ed25519 -C "Mein Kommentar“

Für die Verwendung der Keys in Automatisierungen gebe ich kein Password für den PrivKey ein und für den Speicherort gebe auch auch nur <Return> ein. Dann erfolgt in der Regel die Speicherung unter dem Benutzerkonto im versteckten Ordner .ssh und auf Linux-Systemen im Home-Verzeichnis des nutzenden Users ebenfalls im Verzeichnis .ssh.

Es entstehen dann die beiden Dateien

• id_ed25519.pub (Öffentlicher Schlüssel PubKey)

• id_ed25519 (Privater Schlüssel PrivKey)

Für die Sicherheit der Methoden ist es essenziell, dass der PrivKey nicht in falsche Hände gerät. Das gilt um so mehr, wenn der Schlüssel ohne Password erstellt wird, um ihn in automatisierten Verbindungen effizienter nutzen zu können. Dazu ergreift man neben einem besonders sorgfältigen Umgang, mehrere zusätzlich Maßnahmen, wie versteckte Ordner, stark eingeschränkte Rechte auf Ordner und Datei etc.

Schlüssel austauschen

Der Öffentliche Schlüssel (PubKey) mit der Endung pub muss in der Gegenstelle hinterlegt werden. Dazu gibt‘s verschiedene Methoden, wie zum Beispiel mit a)  ssh-copy-i oder Windows-User nehmen meist b) PuTTY, ich bevorzuge c) FileZilla und für Server-Neuinstallationen (Ubuntu) hinterlege ich den öffentlichen Schlüssel auf meinem persönlichen d) GitHub Konto.

Hier der Syntax für a) ssh-copy-i der zB an der Konsole angewendet wird, wo vorher das Schlüsselpaar erzeugt wurde.

ssh-copy-id benutzername@zielserver

Dabei wird der lokal bereits vorhandene öffentliche Schlüssel (z. B. ~/.ssh/id_ed25519.pub) an die Datei ~/.ssh/authorized_keys des angegebenen Nutzers auf dem Zielsystem angehängt.

Ich nutze in meiner Best Practices gerne c) FileZilla, da das Tool kostenlos und plattformübergreifend genutzt werden kann, sich leicht per Drag & Drop bedienen lässt, sichere Protokolle während der Übertragung unterstützt und zusätzlich mit einem Masterpassword abgesichert werden kann. Das alles entbindet einem IT-Adminstrator nicht von seinen Sorgfaltspflichten, wie die FileZilla Installationsdatei nur von einer sicheren und vertrauenswürdigen Quelle herunter zu laden etc. etc. Zwei weitere Nachteile von FileZilla sind, dass a) per Default nicht das Originaldatum der Quelle sondern das Datum des Kopiervorgangs im Ziel gesetzt wird und dass b) keine Ordner und Dateirechte mit FileZilla geändert werden können.

Nun Punkt a) lässt sich durch eine FileZilla Menüeinstellung pro Verbindungs-Datensatz lösen: Menü Einstellungen, Bearbeiten, Übertragungen, „Änderungszeitpunkt der übertragenden Datei beibehalten“ anhaken..

Die Lösung für Punkt b) erfordert nach abgeschlossener Übertragung die Verwaltung der Rechte für Ordner und Datei von der Konsole aus mit Hilfe der Befehle chmod, chown, chgrp etc. auf dem Zielsystem. Darauf gehe ich im nächsten Beitrag „Linux Rechteverwaltung“ und übernächsten Beitrag zum Thema „Zwei Rechner via Schlüsselpaar und ohne Passwordeingabe sicher verbinden“, näher ein.

Doch zuvor hier noch ein paar zusammenfassende Hinweise zu den Rechten:

Rechte SSH-Ordner und SSH-Dateien

Das meist versteckte Verzeichnis für SSH-Schlüssel heißt in der Regel .ssh

Allgemeine empfohlene Rechte für .ssh

• Das .ssh-Verzeichnis: 700 (drwx------) das heißt nur der eigene Benutzer darf darin lesen, schreiben und ausführen – Gruppen und Andere haben keinen Zugriff.

• Private Schlüssel (id_rsa, id_ed25519): 600 (-rw-------)

• Öffentliche Schlüssel (id_rsa.pub, id_ed25519.pub): 644 (-rw-r--r--)

• Authorized_keys: 600 (-rw-------)

Mit diesen Einstellungen sind Verzeichnis und Schlüssel vor unbefugtem Zugriff durch andere Benutzer gut geschützt.

Rechte setzen / ändern chmod

Folgende Befehle werden üblicherweise benutzt

• Verzeichnis: chmod 700 ~/.ssh

• Private Schlüssel: chmod 600 ~/.ssh/id_rsa oder
  chmod 600 ~/.ssh/id_ed25519

• Öffentliche Schlüssel: chmod 644 ~/.ssh/id_rsa.pub oder
  chmod 600 ~/.ssh/id_ed25519.pub

• Authorized_keys: chmod 600 ~/.ssh/authorized_keys
• known_hosts: chmod 600 ~/.ssh/known_hosts

Prüfe unbedingt die Ergebnisse, jeweils mit

ls -l

Hier ein Beispiel für die Datei authorized_keys

root@mail:~/.ssh# cd ~/.ssh
root@mail:~/.ssh# ls -l
total 0
-rw------- 1 root root 0 Okt 21 18:47 authorized_keys
root@mail:~/.ssh#

Hier noch ein Beispiel für die Rechte setzen vom Benutzer otto für einen PrivKey und die anschließende Abfrage im Verzeichnis .ssh mit ls-lachs

otto@mail:~/.ssh$ chmod 600 ~/.ssh/id_ed25519
otto@mail:~/.ssh$ ls -lachs
total 16K
4.0K drwx------ 2 otto otto 4.0K Nov 12 06:31 .
4.0K drwxr-x--- 5 otto otto 4.0K Nov 11 18:53 ..
4.0K -rw------- 1 otto otto 401 Nov 11 11:55 authorized_keys
4.0K -rw------- 1 otto otto 464 Nov 12 06:50 id_ed25519

Hier noch ein anderes Beispiel

root@mail:/etc/ssh# ls -l
total 540
-rw-r--r-- 1 root root 505426 Apr 11 2025 moduli
-rw-r--r-- 1 root root 1650 Jun 26 2024 ssh_config
drwxr-xr-x 2 root root 4096 Jun 26 2024 ssh_config.d
-rw-r--r-- 1 root root 3249 Okt 21 21:12 sshd_config
drwxr-xr-x 2 root root 4096 Okt 21 18:47 sshd_config.d
-rw------- 1 root root 525 Okt 21 18:47 ssh_host_ecdsa_key
-rw-r--r-- 1 root root 187 Okt 21 18:47 ssh_host_ecdsa_key.pub
-rw------- 1 root root 419 Okt 21 18:47 ssh_host_ed25519_key
-rw-r--r-- 1 root root 107 Okt 21 18:47 ssh_host_ed25519_key.pub
-rw------- 1 root root 2610 Okt 21 18:47 ssh_host_rsa_key
-rw-r--r-- 1 root root 579 Okt 21 18:47 ssh_host_rsa_key.pub
-rw-r--r-- 1 root root 342 Dez 7 2020 ssh_import_id
root@mail:/etc/ssh#

Ende

Hinweis: Ich bevorzuge in meinen Texten aus Gründen der besseren Lesbarkeit das Generisches Maskulinum. Weibliche und andere anderweitige Geschlechtsidentitäten werden dabei ausdrücklich mit gemeint, soweit es für die Aussage erforderlich ist.

Dieser Blog verfolgt keine kommerziellen Interessen. Etwaige Werbung ist kostenfrei! #supportyourlocal