Wie schlimm ist es, mehrere Geräte mit demselben SSH-Server-Schlüssel zu haben?

21

Ich arbeite an einem eingebetteten Gerät, auf dem FreeBSD und SSH ausgeführt werden.

Wie Sie wissen, generiert sshd beim ersten Systemstart gerne zufällig eine Reihe von Serverschlüsseln. Das Problem ist, dass wir das Produkt mit einem schreibgeschützten SD-Kartendateisystem (nicht verhandelbar) versenden.

Meine beiden Optionen, wie ich sie sehe, sind:

  • Versenden Sie auf allen Geräten die gleichen sshd-Serverschlüssel
  • Hängen Sie ein Speicherdateisystem ein und generieren Sie die Serverschlüssel bei jedem Start (langsam ...)

Ist es ein großes Sicherheitsproblem, auf allen Geräten dieselben Serverschlüssel zu versenden? Diese Artikel werden nicht direkt im Internet verfügbar sein. Gelegentlich befinden sich mehrere Geräte im Besitz derselben Person und im selben Netzwerk.

In den meisten Fällen ist das Gerät nicht mit dem Internet verbunden.

Das Anmelden mit SSH gehört nicht zum normalen Betrieb. Dies dient hauptsächlich dem Komfort der Programmierer und Techniker. Kunden werden sich nicht mit SSH am Gerät anmelden.

Welche Konsequenzen hat die Verwendung derselben Serverschlüssel auf mehreren Hardwaregeräten?

PS Könnte jemand bitte ein Internet-of-Things-Tag erstellen?

EDIT : Ich spreche von der Installation der gleichen privaten Host-Schlüssel auf allen Servern (Geräten). Für öffentliche / private Benutzer-Schlüssel ist derzeit keine Verwendung der schlüsselbasierten Anmeldung geplant - es handelt sich um eine Kennwortanmeldung. Wieder dasselbe Passwort auf allen Servern (Geräten).

Ich weiß, dass dies wahrscheinlich eine schlechte Idee ist. Ich würde gerne wissen, warum genau das eine schlechte Idee ist, damit ich die Kompromisse verstehen kann.

NXT
quelle
Wenn Sie die Host-Schlüssel meinen, erhalten Benutzer mit mehr als einem Gerät abhängig von ihrer ssh-Client-Konfiguration möglicherweise Warnungen. Die größeren Bedenken betreffen tatsächliche SSH-Authentifizierungsschlüssel. Hoffentlich installieren Sie keine privaten Schlüssel, und hoffentlich sind Ihre öffentlichen Schlüssel auf bestimmte Quellnetzwerke beschränkt, und hoffentlich haben Ihre privaten Schlüssel, die Ihren Technikern gehören, eine starke Passphrase, und hoffentlich werden diese Schlüssel nie versehentlich in ein Repo eingecheckt. IoTs bekommen wegen dieser Dinge einen wirklich schlechten Ruf. Das nicht zu sagen, sondern nur zu sagen, das ist ein großes Problem.
Aaron
Ich spreche von der Installation des gleichen privaten Hostschlüssels auf allen Servern, wenn Sie das meinen.
NXT
2
Die Verwendung des gleichen Benutzernamens / Passworts auf allen Geräten ist eine sehr schlechte Idee. Diese sind viel einfacher zu erzwingen als der private Schlüssel, der für die Authentifizierung mit öffentlichem Schlüssel verwendet wird. Auch wenn diese Geräte nicht direkt mit dem Internet verbunden sein sollen, wird es trotzdem jemand tun. Und wenn "nicht direkt verbunden" NAT bedeutet, sind sie genug verbunden ...
Tero Kilkanen
7
Das Freigeben des SSH-Schlüssels bedeutet, dass eine Person, die auf den privaten Schlüssel auf einem Gerät zugreifen kann, die Identität aller dieser Geräte annehmen kann.
user253751
3
Obwohl dies eine interessante Frage ist, sehe ich nichts darüber, was sich auf die Systemadministration bezieht, und ist daher für Serverfehler nicht relevant. Sie möchten eine Debugging- / Diagnoseschnittstelle für ein Embedded-Gerät entwerfen, das Sie ausliefern, und keine Schnittstelle, die für Sysadmins relevant wäre. Diese Frage könnte auf Informationssicherheit migriert werden .
200_success

Antworten:

27

Anstatt hostspezifische Daten wie SSH-Hostschlüssel auf der SD-Karte oder einem anderen schreibgeschützten Medium zu speichern, können Sie diese im NVRAM speichern, wofür sie auf einem eingebetteten System vorgesehen sind. Sie müssen einige benutzerdefinierte Skripts ausführen, um die Schlüssel beim Booten zu speichern und abzurufen, aber die Skripts sind für jedes Gerät genau gleich.

Michael Hampton
quelle
12

Die Auswirkung des Versands desselben Schlüsselpaars mit all Ihren Geräten hängt direkt mit der Sicherheit der Clients zusammen, die eine Verbindung zu ihnen herstellen, da es (von einem SSH-Client aus) nicht möglich ist, das Gerät, mit dem die Verbindung hergestellt werden soll, eindeutig zu identifizieren. Sollte Ihr Schlüsselpaar durchgesickert sein, könnte es für MITM-Angriffe verwendet werden.

Wenn Sie jedoch die Schlüssel bei jedem Start neu generieren, wird auf den Clients eine Warnung ausgelöst.

Als Referenz von man ssh(1):

sshpflegt und prüft automatisch eine Datenbank, die eine Identifikation für alle Hosts enthält, mit denen sie jemals verwendet wurde. Host-Schlüssel werden im ~/.ssh/known_hostsHome-Verzeichnis des Benutzers gespeichert . Darüber hinaus wird die Datei /etc/ssh/ssh_known_hostsautomatisch auf bekannte Hosts überprüft. Alle neuen Hosts werden automatisch zur Benutzerdatei hinzugefügt. Wenn sich die Identifikation eines Hosts ändert, wird sshdies gewarnt und die Kennwortauthentifizierung deaktiviert, um Server-Spoofing oder Man-in-the-Middle-Angriffe zu verhindern, die ansonsten zur Umgehung der Verschlüsselung verwendet werden könnten. Mit dieser StrictHostKeyCheckingOption können Anmeldungen an Computern gesteuert werden, deren Hostschlüssel nicht bekannt ist oder sich geändert hat.

Dawud
quelle
2
Ich verstehe nicht, warum sie nicht einfach einmal (auf jedem Gerät beim ersten Start) und dann nie wieder (sofern sie nicht entfernt werden) generieren können.
djsmiley2k - CoW
Perfekt machbar. Das OP gibt jedoch Folgendes an: 'Hängen Sie ein Speicherdateisystem ein und generieren Sie die Serverschlüssel bei jedem Startvorgang'. Meine Antwort geht also davon aus.
Dawud
ah yup das habe ich verpasst als ich es das erste mal gelesen habe.
djsmiley2k - CoW
5

Es hört sich so an, als ob in der ersten Option die SSH-Schlüssel auf der SD-Karte verfügbar wären. So kann jeder Benutzer die Karte nehmen und vorlesen. Grundsätzlich sind Ihre privaten Schlüssel (meistens) öffentlich geworden.

Dies ermöglicht Man-in-the-Middle-Angriffe wie die folgenden:

  1. Ein Benutzer richtet einen SSH-Server mit den von Ihrem Gerät erhaltenen privaten Schlüsseln ein und gibt diese IP-Adresse an Ihren Techniker weiter.
  2. Ihr Techniker gibt das Root-Passwort über die SSH-Verbindung ein.
  3. Der Benutzer kennt jetzt das Root-Passwort, das für alle Ihre Geräte gültig ist.

Sie sollten jedoch nicht zuerst Root-Passwörter verwenden, sondern stattdessen SSH-Schlüssel zur Authentifizierung verwenden. Dann ist die Auswirkung von gemeinsam genutzten Serverschlüsseln ziemlich gering, wenn Sie sich nur über ein LAN anmelden.

SSH bietet auch Vorwärtsgeheimnis, daher muss ein Angreifer in der Lage sein, einen falschen Server einzurichten, um von den Schlüsseln zu profitieren. Wenn Sie den Datenverkehr passiv abhören, können Sie ihn nicht entschlüsseln.

jpa
quelle
Es ist lustig, wie unsere Vorurteile uns (mich) blenden können. Die SD-Karte befindet sich im Gerät hinter einer Verkleidung und unter einer Leiterplatte, sodass mir nie aufgefallen ist, dass jemand sie herausziehen würde. Sie haben jedoch Recht, es ist absolut für jeden mit einem Schraubenzieher zugänglich. Vielen Dank für die Erinnerung, die physische Sicherheit des Systems zu berücksichtigen.
NXT
WRT # 2, das root-Passwort sollte nicht über die SSH-Verbindung gesendet werden. Es sollte in den Terminal-Client eingegeben und für die lokale Hälfte eines Authentifizierungsprotokolls verwendet werden, das den Besitz des Geheimnisses nachweist, ohne das Geheimnis zu übertragen ("Wissensnachweis"). Sogar jahrzehntealte Systeme wussten, dass ein Hash des Passworts und nicht das Passwort selbst gesendet wurde. Nehmen Sie eine Nonce in das Challenge / Response-Protokoll auf, und der Angreifer kennt weder das ursprüngliche Passwort noch ein Token, das an seiner Stelle verwendet werden kann.
Ben Voigt
1
@BenVoigt Ich denke, dass die meisten Unix-Systeme das Passwort an den Server übertragen. Die Schattendatei speichert nur einen Hash, aber Sie möchten einem vom Client generierten Hash nicht vertrauen, da sich sonst jeder mit einem gestohlenen Hash anmelden könnte, ohne ihn umzukehren. Der Server muss also das tatsächliche Kennwort kennen, um bcrypt oder ähnliches ausführen zu können.
jpa
2

Das habe ich entsetzt gelesen! Ich würde es niemals wagen, dies zu tun, wenn ich mehrere Maschinen in demselben Cluster mit demselben SSH-Hostschlüssel ausgeführt habe. Erlauben Sie auf keinen Fall Computern mit unterschiedlichen Administratoren, SSH-Hostschlüssel gemeinsam zu nutzen. Auf diese Weise entsteht Wahnsinn und schreiendes Entsetzen, wenn Sie aus Sicherheitsgründen abgesetzt werden.

Siehe, ich sage dir die Wahrheit, wer ein Gerät kompromittiert, kompromittiert sie alle. Erwarten Sie, dass böse Menschen nach Belieben von einem zum anderen springen, und die Sicherheitskontrolle rollt zurück, als wäre es dünnes Papier.

Joshudson
quelle
1
Könnten Sie erläutern, wie ein Angreifer einen gestohlenen privaten Server-Schlüssel verwenden würde, um andere Geräte zu gefährden?
jpa
@jpa: Für Host-Schlüssel, durch Abfangen und Stehlen von Passwörtern usw. Auch bei diesem Setup wird anscheinend vorgeschlagen, dasselbe mit Benutzerschlüsseln zu tun.
Joshudson
1

Da Sie erwähnen, dass der SSH-Zugriff nicht vom Endbenutzer / Kunden verwendet wird, möchten Sie möglicherweise den SSH-Zugriff standardmäßig deaktivieren und ihn nur vorübergehend aktivieren, wenn das Gerät in den "Debug" -Modus versetzt wird.

Sie können dann entweder alle Geräte mit demselben Schlüssel ausliefern, vorausgesetzt, Sie haben den "Debug" -Modus geschützt, sodass er nicht von jemandem remote ausgelöst werden kann, der versucht, das Gerät zu hacken.

Oder Sie haben einen neuen Schlüssel generiert, wenn das Gerät in den "Debug" -Modus wechselt. So müssen Sie nicht bei jedem Einschalten des Geräts die Startzeit für die Generierung der Schlüssel verschwenden.

Edders
quelle
Ich mag diese Idee.
NXT
1

Hier ist ein Beispiel für ein Angriffsszenario, das auf den Einschränkungen basiert, die Sie haben:

Wenn Ihre Geräte sind, sagen Sie zum Beispiel ein Himbeer-Pi. Wenn ich nach oben gehe und die SD-Karte von einer ziehe, kann ich die SD-Karte in meinen eigenen Computer stecken, den SSHD-Schlüssel finden und an jeden beliebigen Ort kopieren. Vielleicht greife ich zu meinem eigenen Himbeer-Pi und einer USB-Ethernet-Karte. Jetzt kann ich das zwischen ein Zielgerät und irgendwo hin stecken und nach ssh-Verbindungen suchen. Wenn ich sehe, dass das Zielgerät versucht, eine SSH-Verbindung herzustellen, gehe ich folgendermaßen vor:

(target) <---> (my evil sshd <--> decrypted traffic <--> ssh) <---> (real server)
                                       |
                                       V
                                    log file

Oh, was ist das? Ihr Passwort lautet "Ich mag Katzen"? Junge, das ist eine interessante E-Mail, die du deiner Frau geschickt hast. Ich wette, es wäre noch interessanter, wenn sie diese E-Mail lesen würde, die Sie an die Frau Ihres Nachbarn geschickt haben.

Die Möglichkeiten sind endlos . Und das Ziel würde es nie erfahren, da der sshd-Schlüssel mit dem auf dem realen Server identisch ist. Abhängig von der physischen Sicherheit der Einrichtungen, die Ihr Gerät empfangen, kann dies unglaublich trivial sein. Mach das nicht.

Tun Sie stattdessen das, was Sie bereits vorgeschlagen haben, und beheben Sie es . Bevor Sie Ihr Bild schreiben, führen Sie Folgendes aus:

ssh-keygen -f some-new-server
cp some-new-server /path/to/the/mounted/image/sshd/key
cp some-new-server.pub /path/to/the/mounted/image/sshd/key.pub

Und jetzt hat jeder Server einen neuen Schlüssel. Weil Sie wirklich, wirklich keine Kopien eines Schlüssels verteilen wollen. Ich meine, ehrlich gesagt ist es mindestens so schlimm, als würden Sie ein Bild Ihrer Hausschlüssel machen und diese mit Ihrer Privatadresse ins Internet hochladen.

Wayne Werner
quelle
1
Wenn jemand physischen Zugriff auf Ihre Hardware hat und Sie die Daten im Ruhezustand nicht verschlüsseln können, sind alle Wetten deaktiviert.
user9517 unterstützt GoFundMonica