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

[Tommes]

Es hat mir jetzt doch keine Ruhe gelassen

Man benötigt überhaupt kein Script, um einen verschlüsselten Ordner auf der Synology NAS aus der Ferne einzuhängen oder zu trennen. Man benötigt einfach nur eine SSH Public Key Authentifizierung und schon kann es losgehen. Wie man einen solchen Public Key erstellt, soll jetzt nicht Gegenstand dieser Unterhaltung sein. Passende Informationen lassen sich an vielen Stellen im Internet finden. Ohne diese Art der Authentifizierung wird es allerdings etwas schwierig.

Wenn man es dann endlich geschafft hat, solch eine Verbindung einzurichten, braucht man nur noch folgende Befehle per SSH in Richtung Synology NAS abzufeuern (Optionsschalter für Port etc. kneife ich mir jetzt mal)

​

Syntax, um einen verschlüsselten Remote-Ordner einzuhängen bzw. zu mounten​

ssh root@IP-DEINER-SYNOLOGY-NAS -t "/usr/syno/sbin/synoshare --enc_mount SHARE PASSWORD"

Beispiel

ssh root@192.168.178.99 -t "/usr/syno/sbin/synoshare --enc_mount Tresor 12345678"

Syntax, um einen verschlüsselten Remote-Ordner zu trennen bzw. zu unmounten​

ssh root@IP-DEINER-SYNOLOGY-NAS -t "/usr/syno/sbin/synoshare --enc_unmount SHARE"

Beispiel

ssh root@192.168.178.99 -t "/usr/syno/sbin/synoshare --enc_unmount Tresor"

Habe soweit alles durchgetestet und konnte keine Sicherheitslücken feststellen, bis auf die Tatsache, das das Passwort im abzusetzenden Befehl immer noch als Klarname da steht. Durch die SSH-Verbindung ist dieser Befehl aber soweit sicher und wird auch nicht in der bash_history.log abgelegt. Evtl. gibt es irgendwo noch ein SSH Protokoll, wo das Passwort ebenfalls hinterlegt wird, bisher habe ich jedoch noch nichts dergleichen gefunden.

So @scriptius, ich hoffe, dass dir das weiterhilft und ich heut Nacht ruhig schlafen kann

Tommes

 

[scriptius]

Das kenne ich, wenn es einem keine Ruhe lässt .

Die SSH Key Anmeldung klappt (habe ich grade heute eingerichtet) und Deine Syntax funktioniert! Prima, ich danke Dir. Erleichtert es deutlich. Dir noch einen schönen Sonntag.

 

[Furchensumpf]

Moin...

ich komme vom folgenden Thread, bei dem nette User bereits ein wenig Vorarbeit geleistet haben (dank vor allem an (Major?) @peterhoffmann !).

https://www.synology-forum.de/threads/verschluesselte-ordner-wie-automatisch-einbinden.134191/

Ich poste mein Problem mit dem Gedanken jetzt hier, falls andere mit dem Script gleiche Probleme haben und das Ganze an einer Stelle gesammelt bleibt. Hoffe das ist in Ordnung.

Folgendes Szenario, was ich machen wollte:

Ich habe hier zwei Fritzboxen (6690, 6590), wobei ich die 6590 lediglich als Repeater nutze. Auf beide wollte ich jetzt die Schlüssel aufteilen, wobei bei der 6590 das über einen angehängten USB-Stick, bei der 6690 über den internen NAS-Speicher laufen soll. So kann ich den Zugriff auf die verschlüsselten Ordner durch einfaches ziehen des USB-Sticks (z.B. bei Urlaub) verhindern. Da sowohl meine DS und die beiden Fritzboxen nicht nur in verschiedenen Zimmern befinden, sondern sich auch über zwei Etagen verteilen, halte ich das für "recht" sicher.

Ich habe dann im Admin-Verzeichnis unter homes zwei Ordner (crypt1, crypt2) angelegt, wobei ich bei crypt2 einen direkten Remote-Ordner zur 6690 eingerichtet habe, da die 6590 mit dem Stick über das Script in crypt1 eingebunden wird. Da die DS anscheinend den letzten Ordner des entfernten Gerätes anzeigt, kann ich leider nicht direkt in den Ordner gelangen, in dem der Schlüssel liegt. In den beiden Verzeichnen liegt jeweils eine Textdatei (note1.txt, note2.txt), in denen das geteilte PW liegt.

Das automatische Einbindne und Entschlüsseln der Ordner wollte ich jetzt über das Script von @kev.lin realisieren. Das habe ich folgendermaßen angepasst:

#!/bin/bash
### Eine Variable, die den Namen des lokalen Servers (DiskStation) enthaelt
server="ds218plus"
### Adresse/Pfad des SMB-Ordners, der auf einem anderen Server liegt. Dieser Server kann im LAN oder in der Cloud sein
remotepath="//192.168.1.XXX/fritz.nas/Sharkoon-Flexi-DriveEC2-05/note"
### Adresse/Pfad, wo "remotepath" lokal eingebunden werden soll
mountpoint="/volume1/homes/NUTZERNAME/crypt1/"
### der Ordner, der den lokalen Teil des Passwords enthaelt
local="/volume1/homes/NUTZERNAME/crypt2/Note"
### Username und Passwort fuer den Nutzer des einzubindenden Servers - SMB/CIFS-Verbindung
username="Synology"
password="PASSWORT"
### das Share wird lokal unter "mountpoint" eingebunden
mount -t cifs -o vers=3.0,username="$username",password="$password" "$remotepath" "$mountpoint"
### Namen der Ordner, die entschluesselt werden sollen
### es wird ein Ordern nach dem anderen durchgegangen (Schleife)
folders=(Test)
for i in ${folders[@]}; do
pwremotepart1=$(<$mountpoint${server}${i}part1)
pwlocalpart2=$(<$local${server}${i}part2)
pw="$pwremotepart1$pwlocalpart2"
/usr/syno/sbin/synoshare --enc_mount $i $pw
done
### Der Ordner "remotepath", der unter "mountpoint" eingehaengt war, wird wieder ausgehangen
umount $mountpoint

Das Script habe ich als "Ausgelöste Aufgabe" in den Aufgabenplaner eingefügt. Wenn ich dieses jetzt ausführe, kommt folgende Fehlermeldung:

mount: only root can use "--options" option
/volume1/docker/reports/Verschluesselung/1718197982/script.log: line 19: /volume1/homes/Michael_Admin/crypt1/ds218plusTestpart1: No such file or directory
/volume1/docker/reports/Verschluesselung/1718197982/script.log: line 20: /volume1/homes/Michael_Admin/crypt2/Note/ds218plusTestpart2: No such file or directory
/volume1/docker/reports/Verschluesselung/1718197982/script.log: line 22: /usr/syno/sbin/synoshare: Permission denied
umount: /volume1/homes/NUTZERNAME/crypt1: not mounted.

Ich kann mir vorstellen, was mir die Fehlermeldung sagen will - das die Ordner ds218plusTestpart1 und ds218plusTestpart2 nicht gefunden werden - aber wo kommen die her? Test ist bei mir ja der verschlüsselte Ordner. Und oben wird vom Namen meiner DS geschrieben, nicht von einem Pfad.

Hätte evt. jemand eine Idee, wo das Problem liegen könnte? Ich verliere da so langsam den Überblick...^^

Danke

Frederick

 

[alexhell]

Hast du die Aufgabe auch als root ausgeführt?

 

[Furchensumpf]

Das war zumindest ein Teil des Problems...^^

Jetzt bleibt nur noch

/volume1/docker/reports/Verschluesselung/1718200677/script.log: line 19: /volume1/homes/NUTZERNAME/crypt1/ds218plusTestpart1: No such file or directory
/volume1/docker/reports/Verschluesselung/1718200677/script.log: line 20: /volume1/homes/NUTZERNAME/crypt2/Note/ds218plusTestpart2: No such file or directory
Not enough argument. [sharename password] are required

Ist mit dem "sharename password" der Zugang zur Fritzbox gemeint? Den habe ich gerade noch mal ausprobiert, ist richtig. Auf beiden ist der gleiche Nutzer mit gleichen PW angelegt.

 

[alexhell]

Log dich doch mal per SSH ein und wechsel zum user root und dann führ das mal alles per Hand nach und nach aus.....

 

[Furchensumpf]

Ok, ich hoffe dass ich das jetzt richtig gemacht habe. Du meintest quasi die einzelnen Zeilen des Scripts über die Konsole eingeben, richtig? Da nicht mehr direkt auf root zugegriffen werden kann habe ich mich mit meinem Admin-Account angemeldet und alles per sudo -i gemacht (habe ich zumindest so hier im Forum gefunden). Ich komme dabei bis zu

sudo -i mount -t cifs -o vers=3.0,username="$username",password="$password" "$remotepath" "$mountpoint"

Da bekomme ich dann die Fehlermeldung "mount: bad usage"...

 

[alexhell]

Die Variablen sind auch definiert? Und ist das die komplette Fehlermeldung?

 

[Tommes]

Ich kann mir vorstellen, was mir die Fehlermeldung sagen will - das die Ordner ds218plusTestpart1 und ds218plusTestpart2 nicht gefunden werden - aber wo kommen die her?

Die baust du dir in der for-Schleife zusammen.

folders=(Test)
for i in ${folders[@]}; do
pwremotepart1=$(<$mountpoint${server}${i}part1)
pwlocalpart2=$(<$local${server}${i}part2)
...
..
.

… wobei ${server}${i}part1…

ds218plusTestpart1

… und ${server}${i}part2…

ds218plusTestpart2

… entspricht.

Warum du aber ein Array erstellst, welches nur den Namen Test enthält und dieses dann an die Schleife übergibst, ist mir noch nicht ganz klar.

 

[Furchensumpf]

Das PW und den Nutzer habe ich vorher über username="XXX" und password="XXX" wie oben im Script eingegeben...

@Tommes
Nicht das wir uns falsch verstehen - das Script ist nicht von mir, sondern von @kev.lin - ich habe es nur wie in seinem Thread angegeben mit meinen Daten gefüllt. "Test" ist hierbei der Test-Ordner, mit dem ich das Script prüfen wollte. DS218plus ist also die DS, Test der geschützte Ordner auf ihr.

 

[Tommes]

Wenn du bereits als Benutzer root im Terminal angemeldet bist, brauchst du kein sudo und schon gar kein sudo -i mehr vor den mount-Befehl oder irgendeinem anderen Befehl davor zu setzen.

 

[Furchensumpf]

Ja, aber root geht doch nicht mehr per SSH, oder? Bei mir kam nur "access denied" - im Forum stand hier dazu, dass Synology bei der DSM 6 irgendwann mal eingeführt hat, dass man root nicht mehr per SSH aufrufen kann - und für solche Anweisungen eben sudo -i genutzt werden soll...

 

[plang.pl]

Bei sudo -i wechselst du ja zum Root.
Und mit keyless Authentication geht das sehr wohl noch. Nur nicht mehr per Passwort (zumindest wenn man nicht pfuscht)

 

[Tommes]

Was steht denn bei dir in grün vor dem @-Zeichen im Terminal? Ich sehe da ein root@DS218Plus, also bist du als root im Terminal angemeldet.

BTW: fremde Scripte zu nutzen ist das Eine, diese aber zu verstehen und auf seine eigenen Bedürfnisse anzupassen, ist etwas ganz anderes. Du solltest also versuchen zu verstehen, was das Script tut, sonst wirst du es sehr schwer haben.

 

[alexhell]

Da kann ich @Tommes nur zu stimmen. Blind Sachen zu übernehmen kann böse Folgen haben.

 

[Tommes]

Ja, aber root geht doch nicht mehr per SSH, oder? Bei mir kam nur "access denied

Du kannst dich nur indirekt als root aufschalten, außer du nutzt z.B. eine Public Key Authentifizierung. Ansonsten ist der Weg nur über den Admin möglich, sprich Anmeldung ans Administrator und dann wechseln zu root mit sudo -i mit dem Passwort des Administrators

 

[Furchensumpf]

@Tommes
Stimmt, fällt mir jetzt erst auf. nach dem ersten sudo -i ist er anscheinend nach der PW-Eingabe zum root gewechselt.

Wegen dem Script: ich hatte das im Thread so verstanden, dass das Script als Vorlage genutzt werden kann und nur die entsprechenden Änderungen gemacht werden sollen/müssen - damit auch Nutzer wie ich die verschlüsselten Ordner sicherer Nutzen können. Die Werte werden dann ja über die Variablen geholt...und da es anscheinend bei den anderen ohne Probleme funktioniert hat....

Ansonsten werde ich den Weg über den irgendwo festgezurten USB-Stick gehen müssen...

 

[Tommes]

Nur ein Beispiel:

volume1/homes/NUTZERNAME/crypt1/ds218plusTestpart1

… wird aus der Variabel in der for-Schleife gebaut mit…

pwremotepart1=$(<$mountpoint${server}${i}part1)

wobei hier der Mountpoint schon nicht stimmen kann, weil du diesen in der Variablen $mountpoint mit…

/volume1/homes/NUTZERNAME/crypt1/Note

… angegeben hast. Wenn du das vergleichst, dann wirst du feststellen, das im oberen Pfad /Note gar nicht vorkommt.

Des Weiteren versucht…

$(<$mountpoint${server}${i}part1)

… den Inhalt der Datei in die Standard-Eingabe zu lesen um den Inhalt zu erfassen. Es wird also nach einer Datei mit dem Namen…

ds218plusTestpart1

gesucht. Mal abgesehen davon, das der Pfad zur Datei eh nicht stimmt. Das kann so nicht funktionieren, daher sagte ich bereits… Du musst versuchen das Script zu verstehen, sonst gibt das keinen.

 

[Furchensumpf]

OK...dann verstehe ich aber das eine oder andere nicht...

Dann wäre mit Part1 der Name der Datei gemeint, welche den Teil des Passwortes enthält?

Wenn dem so ist, warum sollte dann in dem verschlüsselten Testordner nach dem PW gesucht werden? In dem Crypt-Ordner ist ja die REmote-Verbindung zur Fritzbox...

 

[Furchensumpf]

Ich bin jetzt etwas irritiert...

ich habe das Script wie folgt abgeändert:

#!/bin/bash
### Eine Variable, die den Namen des lokalen Servers (DiskStation) enthaelt
server="ds218plus"
### Adresse/Pfad des SMB-Ordners, der auf einem anderen Server liegt. Dieser Server kann im LAN oder in der Cloud sein
remotepath="//192.168.1.xxx/fritz.nas/Sharkoon-Flexi-DriveEC2-05/note/"
### Adresse/Pfad, wo "remotepath" lokal eingebunden werden soll
mountpoint="/volume1/homes/NUTZER/crypt1"
### der Ordner, der den lokalen Teil des Passwords enthaelt
local="/volume1/homes/NUTZER/crypt2/Note"
### Username und Passwort fuer den Nutzer des einzubindenden Servers - SMB/CIFS-Verbindung
username="Synology"
password="xxx"
### das Share wird lokal unter "mountpoint" eingebunden
mount -t cifs -o vers=3.0,username="$username",password="$password" "$remotepath" "$mountpoint"
### Namen der Ordner, die entschluesselt werden sollen
### es wird ein Ordern nach dem anderen durchgegangen (Schleife)
folders=(Test)
for i in ${folders[@]}; do
pwremotepart1=$(<$mountpoint/note1.txt)
pwlocalpart2=$(<$local/note2.txt)
pw="$pwremotepart1$pwlocalpart2"
/usr/syno/sbin/synoshare --enc_mount $i $pw
done
### Der Ordner "remotepath", der unter "mountpoint" eingehaengt war, wird wieder ausgehangen
umount $mountpoint

- und es funktioniert. Ich habe die DS mehrfach runtergefahren, nach dem Rauffahren war der Ordner entschlüsselt, ich habe den Stick von der Fritzbox gezogen und nach dem Hochfahren war der Ordner geschlossen. Stick wieder drann, hochgefahren, Ordner entschlüsselt.

Ich fand das in der Schleife ein wenig seltsam, warum da der Servername und der Ordner mit im Pfad waren. Vor allem warum die nach dem remote-Pfad (also mountpoint) angegeben wurden. Zudem fand ich es seltsam, dass dort auch der verschlüsselte Ordner vorhanden war - im Grunde (wenn ich das richtig verstanden habe) wurde versucht das Passwort für den verschlüsselten Ordner IM verschlüsselten Ordner zu finden.

Wie es jetzt oben ist funktioniert es...ich weiß aber nicht, ob ich dem so trauen kann.

Noch eine Sache: Wenn ich das richtig sehe, funktioniert das Script doch jetzt nur für Ordner, die alle mit dem gleichen PW verschlüsselt sind, oder? Für Ordner mit verschiedenen Passwörtern bräuchte ich auch verschiedene angepasste Scripte, richtig?