Frage Wie schlimm ist es, mehrere Geräte mit denselben SSH-Serverschlüsseln zu haben?


Ich arbeite an einem Embedded-Gerät, auf dem FreeBSD und SSH läuft.

Wie Sie wissen, erzeugt sshd beim ersten Booten zufällig eine Reihe von Serverschlüsseln. Das Problem ist, dass wir das Produkt mit einem schreibgeschützten SD-Karten-Dateisystem (nicht verhandelbar) versenden werden.

Meine zwei Möglichkeiten, wie ich sie sehe, sind:

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

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

Meistens ist das Gerät nicht mit dem Internet verbunden.

Die Anmeldung mit SSH gehört nicht zum normalen Betrieb. Es ist hauptsächlich für die Bequemlichkeit der Programmierer und Techniker. Kunden melden sich nicht mit SSH auf dem Gerät an.

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

PS könnte jemand bitte ein Internet-of-sachen-tag erstellen?

BEARBEITEN: Ich spreche über die Installation der gleichen privaten Host-Schlüssel auf allen Servern (Geräten). Soweit es öffentliche / private Schlüssel von Benutzern gibt, gibt es derzeit keine Pläne, eine schlüsselbasierte Anmeldung zu verwenden - es wäre ein Passwort-Login. Wieder dasselbe Passwort auf allen Servern (Geräten).

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


21
2017-12-04 17:44


Ursprung


Wenn Sie die Hostschlüssel meinen, erhalten Benutzer mit mehr als einem Gerät möglicherweise Warnungen abhängig von ihrer ssh-Clientkonfiguration. Die größeren Bedenken würden um tatsächliche SSH-Authentifizierungsschlüssel sein. 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 niemals versehentlich in ein Repo eingecheckt. IoTs bekommen einen wirklich schlechten Namen wegen dieser Dinge. Ich würde nicht sagen, dass Sie das tun würden, ich sage nur, dass das ein großes Problem ist. - Aaron
Ich spreche über die Installation des gleichen privaten Host-Schlüssels auf allen Servern, wenn Sie das meinen. - NXT
Die Verwendung des gleichen Benutzernamens / Passworts auf allen Geräten ist eine sehr schlechte Idee. Diese sind viel einfacher zu Brute-Force als der private Schlüssel für die Authentifizierung mit öffentlichen Schlüsseln. Selbst wenn diese Geräte nicht direkt mit dem Internet verbunden sein sollten, wird es trotzdem jemand tun. Und wenn "nicht direkt verbunden" NAT bedeutet, sind sie genug verbunden ... - Tero Kilkanen
Das Freigeben des SSH-Schlüssels bedeutet, dass jemand, der auf den privaten Schlüssel auf einem Gerät zugreifen kann, alle diese Geräte annehmen kann. - immibis
Obwohl dies eine interessante Frage ist, sehe ich nichts darüber, was sich auf die Systemadministration bezieht, und ist daher für Server Fault off-topic. Sie fragen nach dem Entwerfen einer Debugging- / Diagnoseschnittstelle für ein eingebettetes Gerät, das Sie versenden, und nicht einer Schnittstelle, die für Systemadministratoren relevant wäre. Diese Frage könnte zu migriert werden Informationssicherheit. - 200_success


Antworten:


Anstatt hostspezifische Daten wie SSH-Hostschlüssel auf der SD-Karte oder anderen schreibgeschützten Medien zu speichern, können Sie diese im NVRAM speichern, wie es für ein eingebettetes System ist. Sie müssen einige benutzerdefinierte Skripts ausführen, um die Schlüssel beim Systemstart zu speichern und abzurufen, aber die Skripts sind für jedes Gerät identisch.


27
2017-12-04 19:50





Die Auswirkungen des Versands desselben Schlüsselpaars mit all Ihren Geräten hängen direkt von der Sicherheit der Clients ab, die mit ihnen verbunden sind, da es keine Möglichkeit gibt (von einem SSH-Client aus), das Gerät eindeutig zu identifizieren. Sollte Ihr Schlüsselpaar durchgesickert sein, könnte es für MITM-Angriffe verwendet werden.

Auf der anderen Seite löst das erneute Generieren der Schlüssel bei jedem Start eine Warnung auf den Clients aus.

Als Referenz von man ssh(1):

ssh verwaltet und überprüft automatisch eine Datenbank, die die Identifikation für alle Hosts enthält, mit denen sie jemals verwendet wurde. Host-Schlüssel sind in gespeichert ~/.ssh/known_hosts im Home-Verzeichnis des Benutzers. Zusätzlich die Datei /etc/ssh/ssh_known_hosts wird automatisch auf bekannte Hosts überprüft. Neue Hosts werden automatisch der Benutzerdatei hinzugefügt. Wenn sich die Identifikation eines Hosts ändert, ssh warnt davor und deaktiviert die Kennwortauthentifizierung, um Server-Spoofing oder Man-in-the-Middle-Angriffe zu verhindern, die andernfalls zur Umgehung der Verschlüsselung verwendet werden könnten. Das StrictHostKeyChecking Diese Option kann verwendet werden, um Anmeldungen an Rechner zu steuern, deren Host-Schlüssel nicht bekannt ist oder sich geändert hat.


12
2017-12-04 18:25



Ich verstehe nicht, warum sie nicht einfach einmal generieren können (auf jedem Gerät, beim ersten Booten) und dann nie wieder generieren (es sei denn, sie werden entfernt)? - djsmiley2k
Perfekt machbar. Aber das OP sagt, dass er / sie will: 'Montieren Sie ein Speicherdateisystem und generieren Sie die Serverschlüssel bei jedem Booten'. Also meine Antwort geht davon aus. - dawud
ah yup das habe ich verpasst, als ich es das erste mal gelesen habe. - djsmiley2k


Es klingt wie in der ersten Option, die SSH-Schlüssel wären auf der SD-Karte verfügbar. So könnte jeder Benutzer die Karte nehmen und sie auslesen. Ihre privaten Schlüssel sind also (meistens) öffentlich geworden.

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

  1. Ein Benutzer richtet einen SSH-Server mit den privaten Schlüsseln ein, die er von Ihrem Gerät erhalten hat, 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 root-Kennwörter verwenden, sondern stattdessen ssh-Schlüssel für die Authentifizierung verwenden. Dann ist die Auswirkung von gemeinsam genutzten Serverschlüsseln ziemlich gering ob Sie melden sich nur von einem LAN an.

SSH bietet auch Vorwärtsgeheimnis, so dass ein Angreifer in der Lage sein muss, einen falschen Server einzurichten, um von den Schlüsseln zu profitieren; Passives Schnüffeln des Datenverkehrs erlaubt keine Entschlüsselung.


5
2017-12-05 13:00



Es ist lustig, wie unsere Vorurteile uns (mich) blenden können. Die SD-Karte befindet sich im Inneren der Einheit hinter einem Panel und unter einer Platine, so dass mir nie in den Sinn kam, dass jemand sie herausziehen würde. Sie sind jedoch richtig, es ist absolut zugänglich für jeden mit einem Schraubenzieher. Danke für die Erinnerung an die physische Sicherheit des Systems. - NXT
WRT # 2, das Root-Passwort sollte nicht über die SSH-Verbindung gesendet werden. Es sollte in den Terminal-Client eingegeben werden und für die lokale Hälfte eines Authentifizierungsprotokolls verwendet werden, das den Besitz des Geheimnisses beweist, ohne das Geheimnis zu übertragen ("Wissensbeweis"). Selbst jahrzehntealte Systeme wussten, dass sie einen Hash des Passworts und nicht das Passwort selbst senden mussten. Fügen Sie eine Nonce in das Challenge / Response-Protokoll ein, und der Angreifer kennt weder das ursprüngliche Kennwort noch ein Token, das an seiner Stelle verwendet werden kann. - Ben Voigt
@BenVoigt Ich denke, dass die meisten Unix-Systeme das Passwort an den Server übertragen. Die Shadow-Datei speichert nur einen Hash, aber Sie möchten keinen vom Client generierten Hash-Code verwenden, da sich sonst jemand mit einem gestohlenen Hash anmelden könnte, ohne ihn rückgängig zu machen. Der Server muss also das tatsächliche Passwort kennen, um bcrypt oder ähnliches ausführen zu können. - jpa


Ich habe das entsetzt gelesen! Ich, die mehrere Maschinen im selben Cluster mit dem gleichen SSH-Host-Schlüssel gemacht haben, würde es niemals wagen. Unter keinen Umständen dürfen Computer mit unterschiedlichen Gruppen von Administratoren ssh-Hostschlüssel freigeben. Auf diese Weise liegt Wahnsinn und schreiendes Entsetzen, wenn Sie wegen Ihrer mangelnden Sicherheit postiert werden.

Siehe, ich sage dir die Wahrheit, wer Kompromisse ein Gerät macht, kompromittiert sie alle. Einmal erhalten, erwarten Sie, dass schlechte Leute nach Belieben von einem zum anderen springen und die Sicherheit zurückgerollt wird, als wäre es dünnes Papier.


2
2017-12-06 03:56



Können Sie näher erläutern, wie ein Angreifer einen gestohlenen privaten Serverschlüssel verwendet, um andere Geräte zu kompromittieren? - jpa
@jpa: Für Host-Schlüssel, indem Sie Kennwörter usw. abfangen und stehlen. Außerdem scheint diese Einstellung dasselbe mit Benutzerschlüsseln zu erreichen. - joshudson


Da Sie erwähnen, dass der SSH-Zugriff vom Endbenutzer / Kunden nicht verwendet wird, möchten Sie den SSH-Zugriff standardmäßig deaktivieren und 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 einem entfernten Standort ausgelöst werden kann, wenn jemand versucht, das Gerät zu hacken.

Oder Sie haben einen neuen Schlüssel, der generiert wird, wenn das Gerät in den "Debug" -Modus wechselt. So müssen Sie nicht jedes Mal, wenn das Gerät hochgefahren wird, die Zeit für die Generierung der Schlüssel verschwenden.


2
2017-12-06 11:44



Ich mag diese Idee. - NXT


Im Folgenden sehen Sie ein Beispiel für ein Angriffsszenario basierend auf den Einschränkungen, die Sie haben:

Wenn Ihre Geräte sind, sagen Sie zum Beispiel ein Raspberry Pi. Wenn ich aufspringe und die SD-Karte von einem ziehe, kann ich die SD-Karte in meinen eigenen Computer stecken, den sshd-Schlüssel finden und diesen überallhin kopieren. Vielleicht schnappe ich mir meinen eigenen Raspberry Pi und eine USB-Ethernet-Karte. Jetzt kann ich das zwischen einem Zielgerät und wohin auch immer sie hingehen und für SSH-Verbindungen überwachen. Wenn ich sehe, dass das Zielgerät versucht, eine SSH-Verbindung herzustellen, mache ich Folgendes:

(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 Ihrer nächsten Nachbarn geschickt haben.

Die Möglichkeiten sind endlos. Und das Ziel würde es nie erfahren, weil der sshd-Schlüssel mit dem auf dem echten Server gefundenen identisch ist. Abhängig von der physischen Sicherheit der Einrichtungen, die Ihr Gerät empfängt, könnte dies sein unglaublich trivial. Tu das nicht.

Tu stattdessen, was du bereits vorschlägst repariere es. Bevor Sie Ihr Bild schreiben, führen Sie etwas wie folgt 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 eine Neu Schlüssel. Weil du wirklich, Ja wirklich Ich möchte keine Kopien eines Schlüssels verteilen. Ich meine, ehrlich gesagt am wenigsten So schlimm, wie ein Bild von Ihren Hausschlüsseln zu schnappen und sie mit Ihrer Privatadresse ins Internet zu laden.


2
2017-12-06 12:39



Wenn jemand physischen Zugriff auf Ihre Hardware hat und Sie die Daten im Ruhezustand nicht verschlüsseln können, sind alle Wetten deaktiviert. - Iain