Gluon 2014.4 Embedding SSH keys

Hallo Zusammen,

ich habe gerade in der Gluon Doku folgendes entdeckt:

Using gluon-authorized-keys it is possible to embed predefined SSH public keys to firmware images. If gluon-config-mode-* is left out images will be ready to mesh after the first boot with SSH running for further configuration.

Was haltet Ihr davon?

Ich mein generell ist das ne tolle Sache wenn man auf die Router kommt zur Fehlerdiagnose oder um mal ein Autoupdate anzustoßen. Aber ich sehe das ein wenig kritisch auf Routern nen SSH key zu haben die mir nicht gehören. Das erinnert mich so an die Zwangsrouter von Unitymedia etc.

Naja, in der Praxis sieht es so aus, immer wenn man sich beklagt, irgendwas würde nicht nicht richtig laufen, dann werden Daten angefragt, die es nur auf der Konsole gibt.
Und wenn man die dann nicht liefern kann, dann geht’s nciht weiter.

Ist halt leider so.

Ist aber ganz und gar was anderes! Du kannst jeden Router nutzen den du willst. Die Keys kann man auch löschen, d.h. du hast ein Opt-Out. Auch, wenn es nicht jeder kann: geht aktuell sicher nur via console und nicht via Config Mode. Solche Keys müssen aber ziemlich sicher aufbewahrt werden…: bevor ich das einsetzten würde, würde ich ein Konzept erarbeiten und veröffentlichen.

1 Like

Wenn überhaupt würde ich da die Keys unserer Admins also von mir, @Kemal und @Reka reinpacken.

Meiner persönlichen Meinung nach, die schlimmste / blödeste / riskanteste Lösung. Wer Zugriff auf den Key hat, hat auch Zugriff auf das private Netz des Nodebetreibers (in mind 99% der Fälle); ein absolutes „no go“ für Opt-Out, sowas darf nur Opt-In sein. Das Argument „es haben nur zwei, absolut vertrauenswürdige … und alles wird protokolliert“ gibt es da, meines Erachtens, nicht.

3 Likes

Das Feature habe ich entwickelt als ich für eine Veranstaltung 'n paar Dutzend Knoten flashen musste und nicht jedesmal durch den Configmode wollte; und da es praktisch war, hab ich gleich ein Paket daraus gemacht. Dafür pauschal alle Knoten, die man an Freifunker verteilt, mit SSH Keys auszustatten war es nicht unbedingt gedacht.

6 Likes

Da bin ich, bei Dir, auch nicht von ausgegangen. :smile:

Also waren meine Bedenken nicht so falsch bzw. ich bin nicht der einzige der sie hat.

Interessant wäre aber dann vllt ein Feld im Config Mode: Remote Zugriff zulassen ja/nein, Default: nein

2 Likes

Mit einem absolut unmißverständlichem und deutlichem Hinweis darauf, daß dann auch Zugriff auf das private Netzwerk besteht, kann man das machen.

1 Like

Also die Idee war wirklich, dass man entweder gluon-authorized-keys oder den configmode drin hat. Beides zusammen geht natürlich auch. Wenn eine Community Images mit SSH Keys verteilt, sollte sie das IMHO direkt auf der Downloadseite bekanntgeben.

Und nicht nur da. Auch auf der Konfig-Seite und im MOTD (wenn man per SSH auf die Kiste zugreift). Eine solch kritische Information muß multipräsent sein; jedem muß klar sein/werden, daß er sein Netzwerk für Fremde frei zugänglich macht.
Der SSH-Key vermittelt root-Zugriff; alle Zugriffsspuren können spurlos beseitigt werden.

Okay. Dann müsste mal jemand die MOTD in OpenWRT überschreibbar machen. Aktuell ginge das leider nicht.

Also, Freifunk ist für viele technisch Ahnungslose eh eine Sache, die einiges an Vertrauen abverlangt.
Ich würde da nicht automatisch SSH-Keys, auch nicht eines Community-Admins, auf die Nodes packen.

Wenn ich einen Node an jemanden ausgebe, ihn ggfs. noch anschließe, werde ich ihn fragen: willst du den Router selbst warten oder soll ich das übernehmen? Wenn ich das übernehmen soll, muss ich einen Remote-Zugriff per SSH haben. Den habe dann ich und nur ich und der, der den Node bei sich stehen hat, weiß das dann.
Und dann werde ich auch die Konfiguration des Nodes übernehmen und durch den Config-Mode gehen.

2 Likes

Eine weitere Variante wäre einen zusätzlichen User anzulegen und via sudo nur die nötigen Befehle freizuschalten. Und batctrl td wäre dann wahrscheinlich schon ein Kommando, das nicht in die Liste wäre.

Und:

Motivation war hier ganz offensichtlich nicht das Ausspähen von privaten Netzen. Wenn ich Installationen durchführe, biete ich immer an meinen Key zu installieren, incl. dem Hinweis, dass jeder der in den Besitz meines Keys kommt dann in das private Netz vordingen kann. Ich würde den Dampf aus dem Thema also ein wenig rausnehmen.

Genau so machen wir es hier auch; immer mit dem Hinweis, daß wir auch Zugriff auf das priv. Netz haben.

Dampf rausnehmen … Ja, natürlich. Wobei bei mir solchen Sachen aber immer direkt alle Alarmglocken schrillen lassen.
Sachliche Diskusionen sind, bei sowas, aber mehr als angebracht; besonders in der heutigen Zeit.

Das Feature wäre tofte, um besser supporten zu können. Dann wäre das Geschrei nicht dann groß, wenn vergessen wurde Zugang anzulegen und der Router nicht zugänglich ist.

Dafür ist dann wieder das Geschrei groß was man alles böses damit machen kann, wenn ein Feature offen benannt wird, klasse…

Aber fremde Software auf die Router knüppeln, ohne zu wissen was da im Verlauf zwischen OpenWRT Basis und fertigem Firmware Image überhaupt alles möglich gemacht wurde, das ist kein Problem, solange es nicht als Feature ausgewiesen ist?

:blush:

Verstehe ich das richtig - mit SSH Key (oder Passwort) könnte man Zugriff auf das private Netzwerk des Knotenbetreibers nehmen?
Wenn dem so ist, warum darf mir der Abuse-Meister des Vereins Rheinland mit Begriffen wie „Beamtenmentatlität“ und „Troll“ unwidersprochen schmeicheln, wenn ich eine belastbare Regelung aus Datenschutzgründen anrege?

Ahnt ihr überhaupt, was da an Mißtrauen, Demontage den aufstellenden Personen gegenüber zukommen kann und wie eine politische Debatte über Freifunk unter diesen Vorraussetzungen aussehen wird?

Wenn man denn in die Images einen vorinstallierten Key hinterlegen würde.
Hat zumindest bislang niemand vorgeschlagen.

Angedacht ist -wie umschrieben- die Sache für das Ausrollen von größeren Installationen, bei denen die Nodes „mit sinnvollen Defaults“ aus dem Image booten, ohne in einen Setup-/Config-Mode zu gehen.
Und die dann via SSH ggf. noch nachkonfiguiert werden nachdem sie vorher vom Installationstrupp unter die Hallendecke (o.ä.) getackert wurden.

Viel schlimmer Heinz, und deshalb finde ich solche Diskussionen um nützliche Features auch so sinnlos.

Wenn die entsprechende Domäne/Community - bzw. vielmehr einer der Admins der die Firmware baut - die Firmware entsprechend manipulieren würde, die sich jeder ohne mit der Wimper zu zucken installiert, würde ohnehin pauschal und grundsätzlich der Zugriff auf alles bestehen!

Nehmen wir mal unseren Fall. (Und hierbei möchte ich betonen, dass dem nicht so ist!!!)

Wenn der Philip uns wer weiß was in die Firmware kleistert, um Zugriff auf alle Router und alle angeschlossenen Netze zu haben, dann würden wir davon gar nichts merken, es sei denn es fliegt irgendwann durch einen dummen Zufall mal auf…was aber eher unwahrscheinlich wäre.

Wer prüft denn die Firmware „unter der Haube“ darauf, welche „Sonderfunktionen“ eingebaut wurden? Wenn überhaupt werden gewöhnliche Fehler gefunden, aber doch keine echte Diagnose der Software gemacht :wink:

3 Likes