Verschlüsselte Platte über ssh beim booten mounten - wie?

[Sebi_Debian]

Hallo,

ich habe eine Frage zum mounten von verschlüsselten Festplatten.

Die Situation ist folgende:
Ich habe einen PC zu hause, auf dem die Rootpartition verschlüsselt wurde (dmcrypt/luks). Nun habe ich vor, von unterwegs auf die Daten zugreifen zu können (über ssh). Der PC muss also von unterwegs eingeschaltet werden und dann muss später noch das Festplattenpasswort eingegeben werden. Für das erste Problem hab ich schon eine Lösung gefunden, nämlich das Tool "wakeonlan" und eine entsprechende Portweiterleitung im Router. Das klappt auch soweit, ich kann den PC von weit weg aus anschalten. Kurz darauf bleibt er natürlich bei der Passworteingabe stehen.

Ich suche jetzt nach einer Lösung, um das Kennwort zB über eine ssh Verbindung eingeben zu können. Da hab ich natürlich auch erstmal gesucht und bin auf dieses Tutorial gestoßen: http://www.debian-administration.org/articles/579 Ich habe die Anleitung genau befolgt und beim bauen der neuen initrd gab es keine weiteren Probleme. Ich kann mich auch direkt nach dem Laden der initrd über ssh einloggen:

Code: Alles auswählen

sebi@laptop:~$ ssh root@192.168.2.31

     To unlock root-partition run
        unlock

     
root@192.168.2.31's password: 


BusyBox v1.10.2 (Debian 1:1.10.2-1) built-in shell (ash)
Enter 'help' for a list of built-in commands.

Bis jetzt läuft alles so, wie im Tutorial beschrieben. Nur wenn ich den nächsten Schritt, also "unlock" eingeben, befolge, bekomme ich eine Fehlermeldung und die ssh Verbindung wird geschlossen. Ich kann das Passwort danach immer noch nur über den PC selbst eingeben.

Code: Alles auswählen

~ # unlock
~ # Connection to 192.168.2.31 closed by remote host.
Connection to 192.168.2.31 closed.

Ich komme an diesem Punkt nicht mehr weiter, von daher würde ich mich sehr freuen, wenn einer von euch die zündende Idee hätte

grüße,
Sebastian

[jhr-online]

Guck mal genauer in das dropbear script. Da gibt es Info darüber, wie man den ssh im Vordergrund startet um debuggen zu können.

jhr

[Sebi_Debian]

Hi,

ah, okay. Da kommt dann tatsächlich eine Fehlermeldung in der ssh-Konsole:

Code: Alles auswählen

studium@laptop:~$ ssh root@192.168.2.31

     To unlock root-partition run
        unlock

     
root@192.168.2.31's password: 
[1146] Sep 08 20:25:58 lastlog_perform_login: Couldn't stat /var/log/lastlog: No such file or directory
[1146] Sep 08 20:25:58 lastlog_openseek: /var/log/lastlog is not a file or directory!


BusyBox v1.10.2 (Debian 1:1.10.2-1) built-in shell (ash)
Enter 'help' for a list of built-in commands.

~ # unlock
sh: you need to specify whom to kill
~ # unlock
/bin/sh: can't open /scripts/local-top/cryptroot
~ # unlock
/bin/sh: can't open /scripts/local-top/cryptroot

Merkwürdig, dass beim 1. mal irgenwas mit "kill" kommt und danach erst die Fehlermeldung.

Diese Datei "cryptroot" gibt es gar nicht bei mir...

Code: Alles auswählen

~ # ls /scripts/local-top/                
cryptopensc      cryptroot_block  lvm              network_ssh
~ #

Ich werd mich mal auf die Suche machen, wo man die fehlende Datei herbekommt.

Gruß und Danke,
Sebastian

[habakug]

Hallo!

Code: Alles auswählen

work@dnsmasq:~$ locate cryptroot
/usr/share/initramfs-tools/hooks/cryptroot
/usr/share/initramfs-tools/scripts/local-top/cryptroot

Gruß, habakug

[Sebi_Debian]

Hi!

Ich hab mal die beiden Dateien in /etc/initramfs-tools/... kopiert, und zwar so:

/etc/initramfs-tools/hooks/cryptroot
/etc/initramfs-tools/scripts/local-top/cryptroot

Ich habe danach mkinitrd ausgeführt (und ja, ich boote auch immer mit der frisch erstellten und nicht ausversehen mit einer alten initrd), aber es hat nicht geholfen, er sagt mir immer noch, dass "cryptroot" fehle. Muss ich die Dateien noch irgendwie in das dropbearscript einbinden?

mfg und danke!
Sebastian

[jhr-online]

Hmm... hast du Etch oder Lenny? Bei mir hat das gerade sauber geklappt... Das einzige, was noch nicht will bei mir, ist wakeonlan über's Internet (siehe PN, Sebastian)...

jhr

[xdanx]

Da möchte ich auch mal was fragen: Inwiefern unterscheidet sich denn das Vorgehen bei Etch und Lenny?

Die von Sebi_Debian verlinkte Anleitung ist ja für Etch ausgelegt. Für Lenny sollte ja eigentlich das ganze gepatched werden, siehe 465901, 465902 und 465903. Dort heißt es:

Package: initramfs-tools
Version: 0.91e
Severity: wishlist
Tags: patch

this patch is part of three patches (initramfs-tools, cryptsetup,
dropbear) which enable mkinitramfs to create initramfss that provide the
ability to log in and unlock a cryptroot during the boot process from
remote via ssh.

Der Patch für dropbear (465903), hat es aber leider nicht mehr in Lenny geschafft.

Wie wäre nun das Vorgehen für Lenny (abgesehen vom manuellen patchen der dropbear-sources)?

[jhr-online]

Ich hab das ganze gerade genau nach anleitung in lenny gemacht.

jhr

[Sebi_Debian]

Hallo,

@jhr-online:

So wie ich das lese, hat das ganze bei dir ja gut funktioniert. Du hast genau wie ich auch lenny. Hast du da einen von den oben erwähnten Patches eingespielt?

mfg

[xdanx]

ich habe es nun auf eine Etch-Installation angewandt. Hatte nach der Vorgehensweise in Lenny gefragt da ich wissen wollte ob es sich lohnt auf den Lenny-Release zu warten. Um es in Etch zum laufen zu bringen war aber einiges an Modifikation des Original-Skriptes notwendig da es ein paar Fehlermeldungen gab. Mit folgender Variante hat es bei mir geklappt: nopaste

Übrigens, wenn man den SSH-Port von Dropbear nicht auf dem Standardport (22) laufen lassen will muss man das im Hook-Skript auch berücksichtigen!

[jhr-online]

So wie ich das lese, hat das ganze bei dir ja gut funktioniert. Du hast genau wie ich auch lenny. Hast du da einen von den oben erwähnten Patches eingespielt?

Ich habe nichts gemacht, was nicht in der Anleitung steht, glaube ich. Läuft mkinitramfs bei dir absolut fehlerfrei durch?

jhr

[habakug]

Hallo!

Läuft mkinitramfs bei dir absolut fehlerfrei durch?

Ich habe danach mkinitrd ausgeführt [...]

Gruß, habakug

[Sebi_Debian]

Hey,

ups Ich habe mich glatt verschrieben. Wie komme ich denn auf mkinitrd?

Ich meinte natürlich "mkinitramfs"! Ich hab den mal zum Test durchlaufen lassen im verbose-mode:
http://nopaste.debianforum.de/11001

So wie ich das sehe, läuft er soweit fehlerfrei durch, bis auf das Ende, da meckert er rum:

Code: Alles auswählen

Building cpio /home/sebastian/test initramfs
cpio: ./etc/dropbear/log/main: Cannot stat: Datei oder Verzeichnis nicht gefunden

mfg

[jhr-online]

Die Datei, die fehlt, ist ein Link, und ich wette, dass der bei dir rot ist, weil die verlinkte Datei fehlt. :)

Code: Alles auswählen

lrwxrwxrwx 1 root root 17  8. Sep 17:08 main -> /var/log/dropbear

Also:

Code: Alles auswählen

touch /var/log/dropbear

Das sollte zumindest den einen Fehler beheben. Probier dann noch mal zu bauen...

jhr

[BeS]

Hallo,

ist jetzt vielleicht nicht eine direkte Hilfe für dein Problem, aber wieso verschlüsselst du überhaupt deine root Partition? Da sind doch in der Regel nur Programme drauf die sich jeder aus dem Internet laden kann. Also nichts was man geheim halten müsste. Entscheidend sind doch die persönlichen Daten, also /home und hierfür könntest du sehr schön pam-mount verwenden. Wenn du dann für die Verschlüsselung das gleiche Passwort wie für den Benutzer wählst, dann wird die Partition beim einloggen automatisch entschlüsselt, egal ob du von der Konsole, gdm, kdm, ssh,... kommst.

Nur mal so als Tip und kleine Anregung.

[jhr-online]

Zum Beispiel, weil in /etc/postfix/main.cf auf die Zugangsdaten fürs Relay verwiesen wird, die ebenfalls in /etc/postfix liegen. :)

jhr

[BeS]

Zum Beispiel, weil in /etc/postfix/main.cf auf die Zugangsdaten fürs Relay verwiesen wird, die ebenfalls in /etc/postfix liegen.

Naja, ich glaube wenn jemand mein Notebook, meine Festplatte oder so klaut, dann hat er andere Interessen oder findet andere Sachen spannend als den Zugang eines Relay. Es gibt ja heute genug kostenlose Mail Provider über die man seine Mails verschicken kann, dazu braucht man nicht meinen Account. Verschlüsselung von Festplatten ist in meinen Augen dann sinnvoll, wenn man sensible (persönliche) Daten hat die nicht in fremde Hände kommen sollen wenn man z.B. sein Notebook verliert oder wenn der Einbrecher den PC mitnimmt und diese Daten liegen in aller Regel in /home

Aber jetzt wieder zurück zum Thema.

[jhr-online]

Es war vielleicht nicht das beste Beispiel, sehe ich ein. Dennoch kann ich mir Gründe vorstellen. Es gibt ja neben Einstellungen, die man verstecken will, auch evtl. Dinge, die in /var/cache oder gar /usr/local liegen, die man nicht gerne verbreitet sehen will. Sicher, wahrscheinlich ist nicht, dass das einen Dieb interessiert, aber denkbar. Noch ein guter Grund, es so zu machen: der Debian Installer macht das so schön. :)
Nebenbei: http://www.youtube.com/watch?v=O_QA4vCJr40 (sicher ist es eh nicht...)

Aber zurück zum Thema... ;-)

[kryzir]

Darüber hinaus ist mit einer offenen root Partition eine Manipulation dieser nicht zu unterbinden.
Im Endeffekt kommt es halt auf den Prozentualen Paranoidanteil eines jeden an.^^