Hoffmann
Anmeldungsdatum: 27. März 2006
Beiträge: 25
Wohnort: Jena
|
Ich würde gerne das script cryptoroot so anpassen das es folgendes macht: Der Passworteingabeteil soll wie folgt realisiert werden: 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15 | ...Vorbereitungsmaßnahmen...
function readPasswortIntoFile {
echo "$1"
read tmp
echo "$tmp" > "$2"
}
readPasswortIntoFile "$Frage" "$passwortDatei" &
while [[ -z "$(cat "$passwortDatei")" ]]; do
:
done
...Nachbearbeitungsmaßnahmen...
|
Aber leider funktioniert das nicht. Auch wenn ich die Funktion readPasswortIntoFile als eigenständige Datei auslagere funktioniert das nicht...
Hat jemand eine Idee?
|
frostschutz
Anmeldungsdatum: 18. November 2010
Beiträge: 7790
|
Es kann immer nur einer lesen, und wenn du auf der Shell etwas in den Hintergrund schickst, dann liest eben die Shell weiter (den nächsten Shell-Befehl). Die Frage ist nun, was du damit eigentlich erreichen willst?
|
theinlein
Anmeldungsdatum: 29. Dezember 2007
Beiträge: 1279
|
Hallo, es kann nicht nur einer lesen. Es ist halt so, dass ein Job, der im Hintergrund läuft, vom Terminal abgekoppelt wird. Das 'read' ist aber hier so geschrieben, dass es an der Standardeingabe abgreifen will; die ist aber dann zu. Warum eigentlich das Ganze in eine Datei schreiben? ... und dann die while-Schleife, wo doch sowieso nur eine Zeile in der Datei stehen kann? Vielleicht solltest du mal genauer beschreiben, was du machen möchtest. Das hilft vielleicht.
|
Hoffmann
(Themenstarter)
Anmeldungsdatum: 27. März 2006
Beiträge: 25
Wohnort: Jena
|
Ich würde gerne die Möglichkeit haben gemäß dem original Verlauf des Skripts das Passwort direkt von der Shell abzugreifen, also wie bei einem ganz normal verschlüsselten System. Oder eben per SSH. Dafür muss es praktisch zwei "Eingabekanäle" für das Passwort geben. Sobald auf einem der beiden Kanäle ein Passwort übermittelt wird soll das System ganz normal weiter machen. Ihr habt natürlich total recht, dass es Quatsch ist, dem "read" welches nicht mehr im Vordergrund läuft eine Eingabe übermitteln zu wollen. Das heißt eigentlich würde ich gerne die Funktion in den Vordergrund schieben und das Skript solange es wartet abkoppeln...
|
jerik
Anmeldungsdatum: 19. August 2006
Beiträge: 425
|
Was willst du den mit deiner Lösung bezwecken? D.h. was ist das eigentliche Problem was du mit den scripten lösen willst. Evtl. gibt es noch andere Lösungsmöglichkeiten. Was ich bisher verstehe ist, das du das Passwort temporär brauchst und nicht dauerhaft. Ohne gescheite Verschlüsselung ist ein Passwort aber hinfällig, somit stellt sich die Frage ob das ganze nicht anders - einfacher - gelöst werden kann? Gruss – jerik
|
theinlein
Anmeldungsdatum: 29. Dezember 2007
Beiträge: 1279
|
... es tut mir leid, aber ich verstehe dich (noch) nicht ... Hoffmann schrieb: Ich würde gerne die Möglichkeit haben gemäß dem original Verlauf des Skripts das Passwort direkt von der Shell abzugreifen,
also wie bei einem ganz normal verschlüsselten System. Oder eben per SSH.
Dafür muss es praktisch zwei "Eingabekanäle" für das Passwort geben.
Den "Originalverlauf" des Scripts (welches Script denn?) kennt hier keiner. Hoffmann schrieb: Sobald auf einem der beiden Kanäle ein Passwort übermittelt wird soll das System ganz normal weiter machen.
Welche Kanaäle meinst du? Hoffmann schrieb: ... dem "read" welches nicht mehr im Vordergrund läuft eine Eingabe übermitteln zu wollen.
... würde ich gerne die Funktion in den Vordergrund schieben und das Skript solange es wartet abkoppeln...
Wozu sollte das gut sein - ein Script beim Warten auf Eingabe "abzukoppeln"? Es wartet doch auf die Eingabe um dann mit den Eingabedaten weiter zu machen - oder? Warten heißt doch, dass es noch keine Daten hat.
|
Hoffmann
(Themenstarter)
Anmeldungsdatum: 27. März 2006
Beiträge: 25
Wohnort: Jena
|
Sorry, dass ich mich so unverständlich ausdrücke, ich versuche es noch mal vollständig:
Im Falle einer verschlüsselten Festplatte läuft ein Skript ab welches unterschiedliche Parameter prüft („Vorbereitungsmaßnahmen“), dann lokal ein Passwort abfragt, und dann die Festplatte aufsperrt („Nachbearbeitungsmaßnahmen”). Ich habe den schönen SSH-Server dropbear gefunden der es mir ermöglicht noch während des Bootprozesses einen SSH-Zugang auf den Server zu bekommen. Nun würde ich gerne als Alternative zur lokalen Passwortabfrage die Möglichkeit haben das Passwort remote an den Rechner zu übermitteln. Dazu würde ich mich gerne in den laufenden Bootprozess einklinken.
Ich hatte mir vorgestellt an der Stelle an der der gesammte Prozess auf die Passworteingabe wartet in das laufende Skript die Möglichkeit hinzuzufügen das Passwort auf anderem Wege zu erhalten. Meine Idee war also, dass das vorhin angesprochene Bootskript nicht auf eine Passworteingabe wartet, sondern darauf, dass das Passwort in eine Datei geschrieben wird und diese in Folge dessen nicht mehr leer ist. Dann wollte ich diese Datei entweder mit Hilfe einer vom Bootskript gestarteten Funktion befüllen die wie bisher das Passwort lokal abfragt. Oder aber remote über den SSH-Server. Das Bootscript heißt cryptroot und ist in jeder Ubuntuinstallation die mit einem verschlüsselten System arbeitet in /usr/share/initramfs-tools/scripts/local-top zu finden. Mein Problem ist also den nicht-linearen Ablauf zu implementieren.
|
uname
Anmeldungsdatum: 28. März 2007
Beiträge: 6030
Wohnort: 127.0.0.1
|
Ich habe zwar nicht verstanden was du vorhast aber zu dem Zeitpunkt wo die Festplatte entschlüsselt wird kann noch gar kein SSH-Server laufen. Maximal macht es Sinn nur teile der Festplatte zu verschlüsseln (z.B. /home), die dann bei der Anmeldung per SSH entschlüsselt werden (gibt wohl PAM-Module dafür). In dem Fall reicht wahrscheinlich das normale SSH-Passwort oder die genutzte Anmelderoutine, kenn mich damit aber nicht aus.
|
Hoffmann
(Themenstarter)
Anmeldungsdatum: 27. März 2006
Beiträge: 25
Wohnort: Jena
|
Was du schreibst ist - glücklicherweise - falsch. Die Festplattenverschlüsselung, zumindest unter Ubuntu ist so realisiert, dass ein kleiner, wichtiger Teil der Festplatte (/boot) unverschlüsselt bleibt, sonst bräuchte man zum Booten einen externen USB-Stick.
Auf der /boot Partition befindet sich jetzt neben dem Kernel eine gepackte Linuxversion die nur sehr abgespeckte Fähigkeiten hat, nichts desto trotz ein vollständiges Linux. Dieses Linux wird dann, ähnlich wie bei Knoppix oder Ubuntu von CD in dem RAM geladen und ausgeführt. Die Erstellung dieses gepackten Linux ist steuerbar und ich habe, kurz bevor ich es geschafft hätte den openSSH Server dort reinzufriemeln ein Packet gefunden welches genau das automatisch tut (oder tun kann): dropbear, direkt aus den Repositorys installierbar.
Und jetzt starte auf meinem Rechner eben schon beim Bootvorgang, genauer in der Grub Load Stage 1.5, auch Netzwerkunterstützung, ein DHCP Client und ein SSH Server.
|
uname
Anmeldungsdatum: 28. März 2007
Beiträge: 6030
Wohnort: 127.0.0.1
|
Ok, das geht natürlich und vor allem habe ich damit nicht gerechnet. Mir ist jedoch nicht klar wie du dieses gebootete System dazu bringen willst das eigentliche Ubuntu zu starten. Vielleicht solltest du das erst mal mit einem unverschlüsselten System und damit ohne die Notwendigkeit des genannten Passwortes versuchen. Wenn das geht solltest du versuchen dein Problem abschließend zu lösen.
|
Hoffmann
(Themenstarter)
Anmeldungsdatum: 27. März 2006
Beiträge: 25
Wohnort: Jena
|
@uname: Ich habe mich intensiv mit dem Booten eines verschlüsselten Systems auseinandergesetzt und durchaus die Frage gestellt für die ich auch eine Antwort suche. Der Bootvorgang ist sehr logisch aufgebaut und läuft wie am Schnürchen. Das ist Standard Code der seit Jahren läuft und den ich auch nur sehr ungern stärker als für meinen Zweck nötig verändern würde. Im Internet spuken auch Lösungsansätze herum die das ursprüngliche Skript blockieren, aber die Helfen mir nicht weiter weil es unsaubere Lösungen sind "quick'n'dirty". Mich interessiert weiterhin die Frage wie ich ein Bash-Skript dazu bringen kann auf zwei Terminals auf eine Eingabe zu warten und je nach dem welche zu erst kommt, diese zu nutzen und die andere Eingabeaufforderung einfach zu schließen. Die ursprüngliche Frage war natürlich selbst beantwortend: Read kann im Hintergrund nicht vom Terminal lesen weil es nicht mehr angekoppelt ist m(
|
theinlein
Anmeldungsdatum: 29. Dezember 2007
Beiträge: 1279
|
Also, was habe ich davon verstanden ... du startest einen Rechner (mit verschlüsseltem Filesystem) und benötigst dann beim Booten ein Passwort.
Das Passwort willst du lokal abfragen und parallel über die Netzwerk-Hintertür von einem entfernten Rechner per SSH besorgen? Jetzt schreibst du, du wollest dich gerne in den Bootprozess einklinken ... Du willst dich per SSH in den bootenden Rechner einloggen und ein Passwort (in einer Datei) hinterlassen? Dann müsste dein Bootvorgang pausieren, bis das Passwort in der bestimmten Datei abgelegt wurde? Egal durch wen das dort abgelegt wird?
|
Hoffmann
(Themenstarter)
Anmeldungsdatum: 27. März 2006
Beiträge: 25
Wohnort: Jena
|
Ja genau. Der Rechner hat ein fertiges Linux gebootet (GRUB Stage 1.5). Von dort aus wird automatisch ein init-Skript aufgerufen welches nacheinander viele andere Skripte aufruft und Ubuntu in den Zustand bootet den wir alle kennen. Dieser ganze Ablauf kommt zum Halten in dem Moment wo der User ein Passwort eingeben soll. Erst wenn das Passwort eingegeben ist kann der Prozess weiterlaufen. Ich will mich irgendwie in diesem Prozess einklinken in dem ich dem Skript das Passwort ENTWEDER lokal ODER auf einer separaten Shell die ich per SSH- geöffnet habe übergebe.
|
track
Anmeldungsdatum: 26. Juni 2008
Beiträge: 7174
Wohnort: Wolfen (S-A)
|
Grundsätzlich würde ich ja niemals ein Passwort in Klartext in eine Datei schreiben .... Aber so viel habe ich verstanden: Du willst 2 oder mehr Konsolen abfragen, das Ergebnis (also das - bitte verschlüsselte ! - Passwort) in eine Datei schreiben, und wenn dort die Zeile voll ist, dann geht es weiter mit dem mounten des verschlüsselten Systems. Richtig verstanden ? ... ok, das würde für mich heißen, von dem Mutterskript aus starte ich auf jeder Konsole ein Tochterskript (mit "&" dahinter, also asynchron), das nichts weiter macht als das Passwort zu erfragen, zu verschlüsseln und in die bewusste Datei einzutragen. Auf jeder Konsole, die in Frage kommt, wird so ein Tochterskript gestartet. Und wenn das Mutterskript ein gültiges Passwort erkannt hat, dann mountet es das verschlüsselte System und killt die Tochterskripte eben alle wieder. So könnte es doch gehen, oder ? LG, track
|
theinlein
Anmeldungsdatum: 29. Dezember 2007
Beiträge: 1279
|
Hallo ja, track, so hätte ich das auch verstanden und auch vorgeschlagen. Die Frage ist - glaub ich - aber auch noch, wie kommt er zu seinen Konsolen? Da das Init-Script ja irgendwie im Hintergrund arbeitet (?) wird dem zu startenden Kindprozess (der ein Passwort abfragen soll) die Standardeingabe fehlen. Das zweite Problem ist ja, wenn er eine alternative Abfrage starten will - soweit ich verstanden habe, auf einem remote Rechner - wie will er da jemanden fragen? Man müsste ja einem bestimmten User auf dem remote System etwas auf den Bildschirm aufpoppen und nach dem Passwort fragen. Das setzt voraus, dass eine Session läuft. Insgesamt ist das Problem hier, dass ein entfernter User in eine laufende Session hineinplatzt und das aus Sicherheitsgründen erst mal nicht erlaubt ist. Oder habe ich da wieder etwas nicht verstanden? Wie soll das Passwort zu dem bootenden Rechner kommen?
|