SSH-Schlüssel

Ein SSH-Schlüssel ist eine Zugangsberechtigung im SSH-Protokoll. Seine Funktion ist ähnlich wie die von Benutzernamen und Passwörtern, aber die Schlüssel werden hauptsächlich für automatisierte Prozesse und für die Implementierung von Single Sign-On durch Systemadministratoren und Power-User verwendet.

SSH-Schlüssel sind Authentifizierungsnachweise

SSH (Secure Shell) wird für die Verwaltung von Netzwerken, Betriebssystemen und Konfigurationen verwendet. Sie ist auch in vielen Dateiübertragungsprogrammen und Konfigurationsmanagement-Tools enthalten. Jedes große Unternehmen nutzt sie, in jedem Rechenzentrum.

SSH-Schlüssel ermöglichen die Automatisierung, die moderne Cloud-Dienste und andere computerabhängige Dienste möglich und kostengünstig macht. Sie bieten Komfort und verbesserte Sicherheit, wenn sie richtig verwaltet werden.

Funktionell ähneln SSH-Schlüssel Passwörtern. Sie gewähren Zugriff und kontrollieren, wer auf was zugreifen kann. Im Identitäts- und Zugriffsmanagement benötigen sie ähnliche Richtlinien, Provisionierung und Kündigung wie Benutzerkonten und Passwörter. Ohne die Kontrolle über SSH-Schlüssel gibt es keine Vertraulichkeit, Integrität oder Garantien für die kontinuierliche Verfügbarkeit von Systemen.

Technisch gesehen sind die Schlüssel kryptografische Schlüssel, die ein Public-Key-Kryptosystem verwenden. Funktionell sind sie jedoch Authentifizierungsdaten und müssen als solche verwaltet werden.

Autorisierte Schlüssel definieren, wer auf jedes System zugreifen darf

Autorisierte Schlüssel sind öffentliche Schlüssel, die Zugriff gewähren. Sie sind analog zu Schlössern, die der entsprechende private Schlüssel öffnen kann.

Weitere Informationen finden Sie auf der speziellen Seite zu autorisierten Schlüsseln.

Identitätsschlüssel identifizieren Benutzer und ermöglichen Zugriff

Identitätsschlüssel sind private Schlüssel, die ein SSH-Client verwendet, um sich bei der Anmeldung an einem SSH-Server zu authentifizieren. Sie sind analog zu physischen Schlüsseln, die ein oder mehrere Schlösser öffnen können.

Autorisierte Schlüssel und Identitätsschlüssel werden gemeinsam als Benutzerschlüssel bezeichnet. Sie beziehen sich auf die Benutzerauthentifizierung, im Gegensatz zu Hostschlüsseln, die für die Hostauthentifizierung verwendet werden.

Weitere Informationen finden Sie auf der speziellen Seite zu Identitätsschlüsseln.

Zertifikatsbasierte Benutzerauthentifizierung

PKI-Zertifikate können ebenfalls zur Authentifizierung verwendet werden. In diesem Fall hat der Benutzer immer noch einen privaten Schlüssel, aber auch ein Zertifikat, das mit dem Schlüssel verbunden ist. Die Technologie wird sowohl in Tectia SSH als auch in OpenSSH unterstützt, mit einigen Unterschieden. Weitere Informationen finden Sie auf der speziellen Seite zur zertifikatsbasierten Authentifizierung in SSH.

Geräteauthentifizierungsschlüssel

Host-Schlüssel authentifizieren Server

Host-Schlüssel werden zur Authentifizierung von Hosts, also Computern, verwendet. Ihr Zweck ist es, Man-in-the-Middle-Angriffe zu verhindern. Weitere Informationen finden Sie auf der separaten Seite über Host-Schlüssel.

Die zertifikatsbasierte Host-Authentifizierung kann in großen Organisationen eine sehr attraktive Alternative sein. Sie ermöglicht es, die Schlüssel für die Geräteauthentifizierung zu rotieren und bequem zu verwalten und jede Verbindung abzusichern.

Bekannte Host-Schlüssel

Eine der einzigartigen Eigenschaften von SSH ist, dass es standardmäßig dem Schlüssel des Hosts vertraut und sich diesen merkt, wenn es sich zum ersten Mal mit ihm verbindet. Dies war ein wesentliches Unterscheidungsmerkmal, das es ermöglichte, SSH basisdemokratisch einzusetzen, da es 1995 keine zentralisierte Schlüsselinfrastruktur für Hosts gab und auch heute (2017) nicht gibt, mit Ausnahme von SSL-Zertifikaten für Webserver. Die daraus resultierende einfache Bereitstellung war einer der Hauptgründe für den Erfolg von SSH.

Die gespeicherten Host-Schlüssel werden als bekannte Host-Schlüssel bezeichnet und sind in einer Datei namens known_hosts in OpenSSH gespeichert. Solange sich die Host-Schlüssel nicht ändern, ist dieser Ansatz sehr einfach zu verwenden und bietet eine recht gute Sicherheit. In großen Organisationen und wenn sich die Schlüssel ändern, kann die Pflege von Dateien mit bekannten Hosts jedoch sehr zeitaufwändig werden. In diesem Fall wird die Verwendung von Zertifikaten für Host-Schlüssel empfohlen. Tectia SSH unterstützt Standard-X.509-Zertifikate für Hosts. OpenSSH hat sein eigenes proprietäres Zertifikatsformat. Der Vorteil von standardbasierten Zertifikaten ist, dass sie von jeder Zertifizierungsstelle (CA) ausgestellt werden können, während für OpenSSH-Schlüssel keine zuverlässigen CAs existieren. Weitere Informationen finden Sie auf der speziellen Seite über Zertifikate mit SSH.

Sitzungsschlüssel

Ein Sitzungsschlüssel in SSH ist ein Chiffrierschlüssel, der für die Verschlüsselung des Großteils der Daten in einer Verbindung verwendet wird. Der Sitzungsschlüssel wird während der Verbindung ausgehandelt und dann mit einem symmetrischen Verschlüsselungsalgorithmus und einem Message-Authentication-Code-Algorithmus zum Schutz der Daten verwendet. Weitere Informationen finden Sie auf der separaten Seite zu Sitzungsschlüsseln.

Wie Sie die schlüsselbasierte Authentifizierung konfigurieren

Die schlüsselbasierte Authentifizierung in SSH wird als Public-Key-Authentifizierung bezeichnet. In der Standardkonfiguration ist sie von Endanwendern leicht zu konfigurieren. Andererseits müssen sicherheitsbewusste Organisationen klare Richtlinien für die Bereitstellung und Beendigung des schlüsselbasierten Zugriffs festlegen.

Wie man die Authentifizierung mit öffentlichen Schlüsseln für OpenSSH einrichtet

SSH-Schlüssel werden typischerweise in einer authorized_keys-Datei im .ssh Unterverzeichnis im Home-Verzeichnis des Benutzers konfiguriert. Typischerweise erstellt ein Systemadministrator zunächst einen Schlüssel mit ssh-keygen und installiert ihn dann als autorisierten Schlüssel auf einem Server mit dem Tool ssh-copy-id. Siehe auch die spezielle Seite zur Konfiguration von autorisierten Schlüsseln für OpenSSH.

Wir empfehlen die Verwendung von Passphrasen für alle Identitätsschlüssel, die für den interaktiven Zugriff verwendet werden. Im Prinzip empfehlen wir, Passphrasen auch für den automatisierten Zugriff zu verwenden, aber das ist oft nicht praktikabel.

Schlüssel im ssh-agent für Single Sign-On speichern

SSH wird mit einem Programm namens ssh-agent geliefert, das die entschlüsselten privaten Schlüssel des Benutzers im Speicher halten und zur Authentifizierung von Anmeldungen verwenden kann. Der Agent kann auch verwendet werden, um auf Schlüssel auf einer Smartcard oder in einem Hardware-Sicherheitsmodul (HSM) zuzugreifen. Wie Sie ihn einrichten, lesen Sie in der Dokumentation zu ssh-agent.

Die Verbindung zum SSH-Agenten kann an einen Server weitergeleitet werden, so dass Single Sign-On auch ab diesem Server funktioniert. Diese Funktion sollte mit Vorsicht verwendet werden, da sie es einem kompromittierten Server ermöglicht, die Anmeldedaten des Benutzers vom ursprünglichen Agenten zu verwenden. Für Power-User in weniger sicherheitskritischen Umgebungen kann die Agentenweiterleitung jedoch eine wichtige Komfortfunktion sein.

Um die Agentenweiterleitung zu aktivieren, setzen Sie AllowAgentForwarding in /etc/ssh/sshd_config auf dem Server und ForwardAgent in der Client-Konfigurationsdatei /etc/ssh/ssh_config auf yes.

Empfohlene Schlüsselgrößen

Wir empfehlen, die Schlüsselgrößen gemäß NIST SP 800-57 zu wählen. Die vom ssh-keygen-Tool verwendeten Standard-Schlüsselgrößen sind im Allgemeinen von akzeptabler Stärke. Da das Protokoll die öffentlichen Schlüssel, die für die Benutzerauthentifizierung zulässig sind, nie offenlegt, sind die für die Schlüssel verwendeten Algorithmen nicht so kritisch wie beispielsweise bei PKI-Zertifikaten.

Für RSA-Schlüssel sind 2048 Bit heute (2017) wahrscheinlich eine gute Wahl. Allerdings empfehlen viele Kryptographen inzwischen den Wechsel zu ECDSA-Schlüsseln und sind der Meinung, dass Fortschritte bei der Faktorisierung großer Ganzzahlen RSA-Schlüssel in naher/mittlerer Zukunft angreifbar machen könnten. Für ECDSA empfehlen wir die Verwendung von 521-Bit-Schlüsseln (sic!), auch wenn 384- oder sogar 256-Bit-Schlüssel wahrscheinlich sicher wären. Es gibt einfach keinen praktischen Vorteil, kleinere Schlüssel zu verwenden.

Speicherort des Identitätsschlüssels

Identitätsschlüssel werden normalerweise im .ssh-Verzeichnis eines Benutzers gespeichert, zum Beispiel .ssh/ssh_id_rsa. Der Standardname der Identitätsschlüssel-Datei beginnt mit id_<algorithm>. Es ist jedoch möglich, beim Erstellen eines privaten Schlüssels einen beliebigen Dateinamen und einen beliebigen Speicherort anzugeben und den Pfadnamen mit der Option -i an den SSH-Client zu übergeben. Zum Beispiel würde ssh -i /home/ylo/secure/my-key [email protected] einen privaten Schlüssel aus der Datei my-key zur Authentifizierung verwenden.

Der Standard-Speicherort des Identitätsschlüssels kann auch in /etc/ssh/ssh_config oder in der Datei .ssh/config des Benutzers mit der Option IdentityFile konfiguriert werden.

Speicherort für autorisierte Schlüssel

Wenn ein Benutzer versucht, sich mit schlüsselbasierter Authentifizierung anzumelden, sucht der OpenSSH-Server nach autorisierten Schlüsseln aus einem Verzeichnis, das in der Serverkonfiguration mit der Option AuthorizedKeysFile angegeben ist. Die Vorgabe ist .ssh/authorized_keys im Home-Verzeichnis des Benutzers.

Dass die autorisierten Schlüssel im Home-Verzeichnis des Benutzers gespeichert sind, bedeutet jedoch, dass der Benutzer neue Schlüssel hinzufügen kann, die Anmeldungen an seinem Konto autorisieren. Das ist bequem, aber der Benutzer kann diese Schlüssel dann an Freunde oder Kollegen weitergeben oder sogar für Bitcoins verkaufen (das ist tatsächlich schon passiert). SSH-Schlüssel sind außerdem permanent und bleiben gültig, bis sie ausdrücklich entfernt werden.

Wenn autorisierte Schlüssel für Root- oder Service-Konten hinzugefügt werden, bleiben sie leicht auch dann noch gültig, wenn die Person, die sie installiert hat, die Organisation verlassen hat. Sie sind auch eine bequeme Möglichkeit für Hacker, sich dauerhaft auf einem System einzurichten, wenn es keine Erkennung und Warnungen über nicht autorisierte neue Schlüssel gibt.

Aus diesen Gründen wollen die meisten größeren Organisationen autorisierte Schlüssel an einen Ort verschieben, der Root gehört, und einen kontrollierten Prozess für die Bereitstellung und Beendigung dieser Schlüssel etablieren.

Verschieben von SSH-Schlüsseln an einen Root-eigenen Ort

Im Prinzip ist das Verschieben von SSH-Schlüsseln an einen Root-eigenen Ort einfach:

Erstellen Sie ein geeignetes Root-eigenes Verzeichnis, z. B., /etc/ssh/keys, unter dem autorisierte Schlüssel gespeichert werden.
Erstellen Sie für jeden Benutzer ein Unterverzeichnis unter diesem Verzeichnis und verschieben Sie die authorized_keys-Datei jedes Benutzers nach /etc/ssh/keys/<user>/authorized_keys.
Schließlich ändern Sie den Satz AuthorizedKeysFile /etc/ssh/keys/%u/authorized_keys in /etc/ssh/sshd_config.

In der Praxis ist dies jedoch nicht immer so einfach, insbesondere in größeren Umgebungen. Benutzernamen können aus Verzeichnissen stammen (z.B. Active Directory oder LDAP). Viele Organisationen haben unterschiedliche OpenSSH-Versionen, einschließlich sehr alter Systeme oder benutzerdefinierter SSH-Builds, die nicht standardmäßig eingebaute Pfade haben. Um diese Komplexität in größeren Umgebungen auszublenden, empfehlen wir die Verwendung von Schlüsselverwaltungstools wie Universal SSH Key Manager. Diese Werkzeuge können auch einen Arbeitsablauf für die Bereitstellung, Beendigung und Genehmigung von Schlüsseln implementieren und Warnungen über nicht autorisierte Änderungen durch Root-Benutzer ausgeben.

OpenSSHs Begrenzung der Anzahl privater Schlüssel

Der OpenSSH-Server hat eine Funktion (ich würde es einen Bug nennen), dass er das Testen, ob ein bestimmter Schlüssel für die Authentifizierung verwendet werden kann, als einen Authentifizierungsversuch zählt. Das hat zur Folge, dass, wenn der Benutzer mehr als fünf Schlüssel in .ssh hat, nur einige von ihnen funktionieren. Dies führt oft dazu, dass die schlüsselbasierte Authentifizierung fehlschlägt und ist für den Benutzer oft schwer zu durchschauen. Eine Möglichkeit, dies zu umgehen, ist die explizite Angabe des zu verwendenden privaten Schlüssels mit der Option -i. Eine Alternative ist die Anpassung der MaxAuthTries-Sitzung auf dem Server, aber dies ist keine vollständige Lösung und es ist nicht wünschenswert, die Anzahl der Versuche zur Passwortauthentifizierung zu erhöhen.

Wie sehen SSH-Schlüssel aus

Ein autorisierter Schlüssel kann so aussehen:

ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBN+Mh3U/3We4VYtV1QmWUFIzFLTUeegl1Ao5/QGtCRGAZn8bxX9KlCrrWISIjSYAwCajIEGSPEZwPNMBoK8XD8Q= ylo@klar

Ein Identitätsschlüssel kann so aussehen:

Wie funktioniert die Authentifizierung bei SSH?

Die Initialisierung einer Verbindung in SSH besteht aus:

Aushandeln der zu verwendenden Version des Protokolls
Aushandeln der zu verwendenden kryptografischen Algorithmen und anderer Optionen
Aushandeln eines einmaligeneinmaligen Sitzungsschlüssel für die Verschlüsselung der restlichen Sitzung
Authentifizierung des Server-Hosts mit seinem Host-Schlüssel
Authentifizierung des Benutzers mit einem Passwort, Authentifizierung mit öffentlichem Schlüssel oder anderen Mitteln.

Danach können Daten ausgetauscht werden, einschließlich Terminaldaten, Grafiken und Dateien.

SSH-Schlüssel - Authentifizierung mit SSH-Schlüsseln

Authentifizierung mit öffentlichem Schlüssel

Der schlüsselbasierte Authentifizierungsmechanismus in SSH wird Public-Key-Authentifizierung genannt. Im Wesentlichen werden einige sitzungsspezifische Daten mit dem privaten Identitätsschlüssel signiert. Die Signatur wird dann an den Server gesendet, der überprüft, ob der zum Signieren verwendete Schlüssel als autorisierter Schlüssel konfiguriert ist. Der Server verifiziert dann die digitale Signatur mit dem öffentlichen Schlüssel des autorisierten Schlüssels. Der Identitätsschlüssel wird nie an den Server gesendet.

Das Wesentliche an der Public-Key-Authentifizierung ist, dass sie es einem Server erlaubt, auf einen anderen Server zuzugreifen, ohne ein Passwort eingeben zu müssen. Diese leistungsstarke Funktion ist der Grund, warum sie für Dateiübertragungen (unter Verwendung des SFTP-Protokolls) und für das Konfigurationsmanagement so häufig verwendet wird. Es wird auch häufig von Systemadministratoren für Single Sign-On verwendet.

Wie verbreitet sind SSH-Schlüssel und wie hoch ist das Risiko

SSH-Schlüssel erweisen sich als extrem verbreitet und weithin genutzt. Viele große Organisationen haben sie seit zwanzig Jahren ohne jegliche Kontrolle angehäuft. Ein typisches Fortune-500-Unternehmen hat mehrere Millionen Schlüssel, die Zugang zu ihren Servern gewähren. In einem Kundenfall haben wir 500 Anwendungen und 15.000 Server untersucht und 3.000.000 autorisierte Schlüssel und 750.000 eindeutige Schlüsselpaare gefunden. Diese Organisation hatte außerdem über fünf Millionen tägliche Anmeldungen mit Schlüsseln. Die Schlüssel wurden für die Ausführung von Finanztransaktionen, die Aktualisierung von Konfigurationen, das Verschieben von Protokolldaten, Dateiübertragungen, interaktive Anmeldungen durch Systemadministratoren und viele andere Zwecke verwendet.

Es zeigt sich, dass die meisten großen Unternehmen Hunderttausende oder sogar Millionen von Schlüsseln haben. Diese Schlüssel sind unkontrollierte Zugriffe, die das gesamte Unternehmen gefährden können.

So eliminieren Sie SSH-Schlüssel vollständig

Mit dem PrivX On-Demand Access Manager können Sie SSH-Schlüssel von Servern vollständig eliminieren und eine richtlinienbasierte Zugriffskontrolle und Sitzungsprotokollierung im gesamten Unternehmen etablieren. Er eliminiert auch den größten Teil des administrativen Aufwands bei der Verwaltung von Schlüsseln und bietet dennoch die Vorteile: Automatisierung und Single Sign-On.