Script: Verschlüsselten Ordner via Keyfile (.key) entschlüsseln

[synfor]

Anzupassen (nach Euren Begebenheiten) sind alle Stellen, die rot hervorgehoben sind: "server", "remotepath", "mountpoint", usw.

• Du hast share1 und share2 vergessen zu markieren.
• Die Farbe ist schlecht gewählt. Sie hebt sich nicht besonders von den restlichen Farben ab.

 

[kev.lin]

Ich finde aber die Begrifflichkeit "externer Server" etwas irritierend. Unter externem Server verstehe ich einen Server, der extern sitzt, also nicht im eigenen Netzwerk.

Gebe ich Dir Recht, die Begrifflichkeit kann missverstanden werden. Ich hatte bei "extern" an "nicht die DiskStation" gedacht.
Ich habe das Script und dessen Kommentare entsprechend angepasst.

 

[kev.lin]

• Du hast share1 und share2 vergessen zu markieren.
• Die Farbe ist schlecht gewählt. Sie hebt sich nicht besonders von den restlichen Farben ab.

Danke für den Hinweis. Aber das kann ich leider nicht beeinflussen. Die Farben werden automatisch gesetzt Man gibt an, dass der Quellcode "Bash" ist und die Passagen werden eingefärbt.

Meine Hoffnung ist, dass Beginner durch den Kommentar

### Namen der Ordner, die entschluesselt werden sollen

selbst darauf kommen, darunter bei

folders=(share1 share2)

die EIGENEN Ordnernamen einzutragen.

 

[synfor]

Ach so, die rote Markierung ist gar nicht von dir.

 

[kev.lin]

Nein, nur im regulären Textbereich. Im Code-Bereich wird das durch die Angabe der Sprache hervorgehoben. Siehe hier:

 

[Lucifor]

Top Beitrag

Dazu gleich eine Frage, wie lang darf das Verschlüsselungspasswort sein? Sind es immer noch maximal 64 Zeichen?

 

[kev.lin]

Danke für die Blumen!

Aber jetzt muss ich leider enttäuschen: die maximale Passwortlänge habe ich nicht überprüft.
Aber wenn Du Dich da ran machst, gib gerne Feedback, damit wir alle etwas davon haben.

 

[peterhoffmann]

wie lang darf das Verschlüsselungspasswort sein?

Einfach mal mit 100 Zeichen und einem Testordner ausprobieren? Dauert 20 Sekunden.

 

[kev.lin]

Stimmt, danke! Da hatte ich ein Brett vorm Kopf! Ich dachte, der Test geht nur über die beiden Teile das Passwort-Files.

 

[scriptius]

Wenn man das so macht, wird dann im bash_history.log trotzdem das Kennwort im Klartext angegeben?
https://superuser.com/questions/1100474/mount-encrypted-folder-on-synology-nas-via-terminal

 

[Tommes]

Hab es grad mal getestet und ja... das ist immer noch so. Sachen gibts

Das kleine Script, welches in deinem Link erwähnt wurde, habe ich ebenfalls getestet und ja... funktioniert auch immer noch.

Tommes

 

[scriptius]

Echt, bei Dir funktioniert das? Ich erhalte eine Fehlermeldung bezgl. der passwordVariable. Vielleicht mache ich aber grundsätzlich was falsch... Aber komisch, dass in der bash_history.log das Kennwort steht, denn im Script von kev.lin wird ja auch nur auf das Passwort verwiesen...

​

 

[Tommes]

Ich habe das so umgesetzt…

#!/bin/bash
# Script name: decrypt-share.sh
# Call: . ./decrypt-share.sh SHARENAME

echo -n "Enter Share Password: "
read -s passwordVariable
echo ""
/usr/syno/sbin/synoshare --enc_mount $1 $passwordVariable

Es ist darauf zu achten, das als Share Name nur der eigentliche Odnername, ohne das @ Zeichen im Präfix und Suffix an das Script übergeben wird.

Das Script von @kev.lin habe ich noch nicht ausprobiert. Ich habe ein eigenes, es aber noch nicht weiter auf diesen Bug hin untersucht.

 

[scriptius]

Mmhh, habe echt keinen Plan..., denke aber mir fehlt was. Muss ich nur Dein Script benutzen und dann sollte es funktionieren?

 

[Tommes]

Ein @scriptius sollte sich die Frage wohl selbst beantworten können!

 

[scriptius]

Äääh, nö

 

[scriptius]

Je mehr ich lese, desto unsicherer wird die Synology-Verschlüsselung... und für mich als Otto-Normalbenutzer (trotz meines Namens ) ist es schwer kompliziert.
Kann ich denn den "normalen" synoshare Befehl nutzen und das bash_history.log deaktivieren oder kann dann immer noch jemand mit physischen Zugriff auf das NAS die Verschlüsselung locker aushebeln?

 

[Tommes]

Der "Otto-Normalbenutzer" muss sich eigentlich nicht mit der Linux-Konsole und kryptischen Befehlsketten auseinandersetzen, da das Einhängen und Trennen verschlüsselter Ordner über den DSM erledigt werden kann. Und daran ist zunächst nichts kompliziert.

Spannend wird es jedoch, wenn man anfängt nach Möglichkeiten zu suchen, einen verschlüsselten Ordner im Notfall selbst und ohne DSM entschlüsseln zu können. Da stößt man dann auf den ein oder anderen Prozess, der sich einem nicht wirklich erschließt. So auch das Thema "Passwort steht als Klarname in der bash_history.log, wenn man den synoshare auf der Konsole abfeuert". Denn eigentlich macht Linux genau das, was es schon immer getan hat, nämlich so viel wie möglich zu protokollieren. Und gäbe es die bash_history.log nicht, würde sich das Debugging oftmals schwieriger gestalten. Von daher ist erst mal alles chic.

Dumm ist halt, das Linux auch den synoshare Befehl in der bash_history.log loggt und somit auch das im Klarnamen eingegebene Passwort. Das hätte Synology eigentlich wissen müssen und daher sowas nicht zulassen dürfen. Daher auch der Umweg über das o.a. Script, da hierbei das Passwort an eine Shell-Variable übergeben wird, dessen Inhalt von der bash_history.log nicht erfasst wird.

Aber... eigentlich kenne ich das auch nicht so, einen verschlüsselten Ordner direkt mit dessen Passwort auf direktem Wege einzuhängen, sondern den Weg über einen Verschlüsselungsschlüssel, dem sogenannten Key-File zu nehmen. Wie das genau funktioniert, ist hier ganz gut beschrieben.

...oder kann dann immer noch jemand mit physischen Zugriff auf das NAS die Verschlüsselung locker aushebeln?

Derjenige, der physischen Zugang zu deiner Synology NAS hat, der wäre wohl auch in der Lage, die bash_history.log auszulesen. Auf der anderen Seite verwendet Synology für die Entschlüsselung des Verschlüsselungsschlüssel ein standardisiertes Passwort, welches sicherlich nicht jeder kennt und ich werde es auch nicht nennen. Kann auch sein, das Synology das Vorgehen mittlerweile geändert hat. Ich bin in dem Thema aktuell nicht ganz drin. Egal...

Ich selber nutze zwar ebenfalls die Ordnerverschlüsselung des DSM, aber ich habe auch ein eigenes Script, welches mir eine individuelle Passhrase für Verschlüsselungsschlüssel erstellt, in dem sich mein eigentliches Passwort befindet. Name und Speicherort des Verschlüsselungsschlüssel kann dann u.a. auch ein externer Datenträger oder eine Remote Freigabe im Netzwerk sein.

Aber ich quatsche schon wieder zu viel...

 

[scriptius]

Verstehe.
Ich habe das Script entsprechend angepasst und in einem Ordner Test gespeichert. Wenn ich über meinen Windows-PC mit Putty und root das Script mit bash scriptname.sh aufrufe, erhalte ich folgenden Fehler:
': not a valid identifierasswordVariable

Not enough argument. [sharename password] are required

Was mache ich denn falsch?

 

[Tommes]

Wenn ich [...] das Script mit bash scriptname.sh aufrufe...

Sollst du ja auch gar nicht. Lesen heißt hier das Zauberwort. So steht in meinem Script in Zeile 2 und 3

# Script name: decrypt-share.sh
# Call: . ./decrypt-share.sh SHARENAME

... was so viel bedeutet wie... rufe das Script, was ich decrypt-share.sh genannt habe, auf der Konsole so auf...

. ./decrypt-share.sh DEIN-ORDNERNAME

BTW: Vielleicht solltest du deinen Benutzernamen mal ändern, da dieser in meinen Augen etwas suggeriert, was du nicht zu sein scheinst. Nicht bös gemeint. Aber wenn jemand so heißt, dann denke ich zunächst, er kennt sich mit sowas aus.

Tommes