Der (IT) Blog aus Braunschweig
Der Vortrag „SSH: All Inclusive“ beim gestrigen Linux am Dienstag steht jetzt zum Download bereit: SSH: All Inclusive
Folgende Themen werden behandelt:
Wie erstellt man einen Key
Was ist ein SSH-Agent
Wie geht man mit Schlüsseln um
Wie kopiert man Dateien mit SCP
Was ist SFTP
Was machen Dateimanager mit SFTP
Was ist und kann SSHFS
Wie bauen wir mit SSH eine Netzwerkbrücke
Wie bauen wir uns ein VPN
Viel Spaß damit.
„Herzlich willkommen zu Ihrem neuen „Ärger den Hoster“ Projekt. Heute wollen wir Ihnen zeigen, wie Sie Webstorageanbieter wie OneDrive oder DropBox in die Knie zwingen können.“ 🙂
LUKS verschlüsselter Cloud-Raid 10
Das ist zwar nicht das Ziel unseres kleinen Projekts, könnte aber passieren ;)Beim letzten Linux am Dienstag, hab es ja leider eine kleine Panne bei der Webserverzertifizierung, was uns aber nicht daran gehindert hat, es doch durchzuziehen 😉 In diesem Rahmen habe ich das Projekt schon einmal Live vorgestellt.
Ihr kennt ja vermutlich den Beitrag, wie man mit SSHFS und Veracrypt einen sicheren Container bei einem Cloudanbieter bauen kann. Das hatten wir ja im Rahmen des letzten LPD 2021.1 vorgestellt. I.d.R. reicht dies für die meisten Sachen völlig aus, hatte aber noch Potential, oder auf Deutsch, ein paar spannende Ecken zum ausforschen, was so geht 😀
Herausgekommen ist eine verschlüsselte, virtuelle Festplatte als RAID 10 mit Spare, die komplett im Netz liegt, aber nur auf dem Lokalen PC vollständig und nutzbar ist. Um die Spannung gleich etwas abzumildern, die Sache mit den Hostern ist, daß sobald sich ein Bit ändert in dem für den Raid genutzten LUKS Container, ist der Container komplett im Backup drin. Wenn der also GBs groß ist, dann belegt das sehr viel Platz im täglichen Backup des Hosters, was Hoster i.d.R. nicht gut finden 😉
Es sind auch alle anderen Raidformen denkbar, von Raid 1 bis 60 . Denkt mal ein bisschen nach, wieso ich da kein Raid 0 liste.
Ist das Internet nicht erreichbar, oder kommt es auf Netzsegmenten zwischen sich und dem Hoster zu Problemen, fällt das Raid ggf. unabsichtlich aus oder kann gar nicht erst gemountet werden.
Der Raidrebuild ist sehr langsam, langsamer als Ihr jetzt vermuten werdet. Bei Tests 128 KB/s, statt mehreren MB/s.
Keine Redundanz auf dem PC
Das Raid kann immer nur von einem PC aus zusammengesetzt werden. Mehrere würden die Daten zerstören, außer Ihr seid völlig durchgeknallte Datenjongleure 😉
Über die Sinnhaftigkeit eines Cloudbasierten virtuellen Raid 10 muß man sich keine großen Gedanken machen, da es nur eine Grenzfallbetrachtung ist.
Auf der anderen Seite, ein Raid 1 mit einem lokalen Bein und einem, oder mehreren, bei einem Cloudhoster, ist schon deutlich sinnvoller. Das lokale Bein (so nennt man eine Seite des Raids ) hat eine extrem hohe Schreib- und Lesegeschwindigkeit (weil im Tests wars eine NVME ), im Vergleich zum Netzwerk. Das führte bei Tests des Systems zu einer schnellen Reaktion, wie bei einer normalen Platte, und im Hintergrund wurde das dann langsaaaammmm synchronisiert. Das fällt dem Nutzer erst dann auf die Füße, wenn er was ins Raid schreibt und dann das Laptop oder den PC abschaltet, bevor das Raid komplett gesynct ist.
Das Raid würde sich beim nächsten mal zwar reparieren, meistens in dem das Spare genutzt wird, so vorhanden, in ganz wenigen Fällen auch einfach weiter syncen. Eine gute Idee ist es definitiv nicht.
Wer Daten vom PC zu einem Cloudanbieter so spiegeln will, daß eine Backupkopie verhanden ist, sollte dort einen LUKS oder VeraCrypt-Container hinterlegen, den per SSFS anbinden, öffnen und dann mit RSYNC oder einem Clusterfilesystem arbeiten.
Da ich keine Lust habe, den 45 Minuten Vortrag nochmal zu tippen, hier die Quelle:
Click to access LAD-Raid-10-in-der-Cloud.pdf
Quelle: https://linux-am-dienstag.de/archiv/LAD-Raid-10-in-der-Cloud.pdf
Man kann das auch mit ZFS bauen. Wie gut da die Krypto ist, kann ich nicht beurteilen. Außerdem ist es nicht auf jedem System drauf und es ist definitiv eher auf physikalische Datenträger ausgerichtet.
Die Sache mit dem kpartx ist eine Nummer, die sich nicht jedem sofort erschließt. Ich rate dazu, wenn Ihr das nachbaut, ein Terminal offen zu haben, das „watch -n 1 lsblk“ anzeigt. Damit wird einiges einfacher zu verstehen.
Die Failzeiten des SSHFS sind willkürlich gewählt, wie es meinem Gusto entsprach. Ihr könnt natürlich selbst entscheiden, ob Ihr da 3 Sekundenoder 30 Sekunden bis zum Fail angebt. Im Vergleich zur Dauer eines Rebuild mit 128 KB/s, sind diese exemplarischen 27 Sekunden natürlich nur eine kurze Zeitspanne.(50 MB Raidfiles => ca. 90 Minuten Rebuild )
Ein Raid 1 mit mehr als einem Cloudhoster ist vermutlich die bessere Wahl, kommt aber aufs Szenario an, welches man abdecken möchte.
Die Doppelte Lage LUKS könnte man auch durch eine LUKS ( Webhoster ) – VeraCrypt – Kombination ersetzen, was andere Verschlüsselungsalgorithmen beinhalten würde, was das brechen der Gesamtverschlüsselung deutlich erschwert. Auch könnte es einem in den Sinn kommen, die LuksFormatierung für jedes Datenfile einzeln zu machen, damit dort andere Kryptokeys im Einsatz sind. Weil, nach dem obigen Plan, sind die alle gleich. Bricht also ein LUKS-Container auf, gehen alle auf. Deswegen wäre es eine gute Idee, die planetenweit zu verteilen, was das Ergreifen der Daten deutlich erschwert.
Von Experimenten wie dem Speichern der Daten auf dem Draht der Netzwerkverkabelung ist dringend abzuraten, weil sich da kein LUKS Container drauf abbilden läßt 😉 Das ist ein echt höchst instabiles Speichermedium, wie unsere Tests bei Linux am Dienstag gezeigt haben 😀
 Icon des Webservers auf dem Desktop | Wer seine Webseiten entwickeln will, muß die irgendwie auf seinen Webspace bekommen. Je nachdem was man programmiert und welche Serverumgebung man hat, kann es auch sein, daß einem der Server einen Deploy Mechanismus anbietet. Das ist z.B. im WebApplicationServer Tomcat so vorgesehen. PHP Anwendungen werden üblicherweise einfach nur in das Public_html des Webspace kopiert und direkt aufgerufen. |
Voraussetzung für dies Verfahren ist, daß man sich auf seinem Webspace per SSH einloggen kann. Könnt Ihr das nicht, sucht Euch einen neuen Anbieter.
Das tun wir hier mal ( den Domainnamen habe ich mal exemplarisch gewählt, den gibt es zwar wirklich, aber nicht bei mir 😉 )
[marius@eve ~]$ ssh webdemode@webdemo.de webdemode@webdemo.de's password:
Passwort eingeben, weil noch geht ja kein Key.
Last login: Sat Mar 31 12:38:16 2018 from 79.239.240.108 [webdemode@s113 ~]$ ls -la total 14 drwxr-x--- 3 webdemode services 4096 Mär 31 09:59 . drwxr-xr-x 13 root root 4096 Mär 31 09:59 .. -rw-r--r-- 1 webdemode webdemode 18 Aug 8 2017 .bash_logout -rw-r--r-- 1 webdemode webdemode 193 Aug 8 2017 .bash_profile -rw-r--r-- 1 webdemode webdemode 231 Aug 8 2017 .bashrc drwxr-xr-x 3 webdemode webdemode 4096 Mär 31 09:59 public_html
Es fehlt das Verzeichnis „.ssh“, also anlegen:
[webdemode@s113 ~]$ mkdir .ssh [webdemode@s113 ~]$ ls -la total 18 drwxr-x--- 4 webdemode services 4096 Mär 31 10:09 . drwxr-xr-x 13 root root 4096 Mär 31 09:59 .. -rw------- 1 webdemode webdemode 229 Mär 31 10:39 .bash_history -rw-r--r-- 1 webdemode webdemode 18 Aug 8 2017 .bash_logout -rw-r--r-- 1 webdemode webdemode 193 Aug 8 2017 .bash_profile -rw-r--r-- 1 webdemode webdemode 231 Aug 8 2017 .bashrc drwxr-xr-x 3 webdemode webdemode 4096 Mär 31 09:59 public_html drwxrwxr-x 2 webdemode webdemode 4096 Mär 31 10:02 .ssh
Noch hat es falsche Rechte, da würde SSH meckern :
[webdemode@s113 ~]$ chmod 700 .ssh [webdemode@s113 ~]$ cd .ssh/ [webdemode@s113 .ssh]$ vi authorized_keys2
Dann den Fingerprint von Eurem Key in die Datei authorized_keys2 reinschreiben:
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAEAQ7v3LaRyRjbm...... Rqr9L8IjxAEeT7bzZ/VH20ksRNwSEU5jnTE7S2Jcvk2u/7CnmipAp/uE2SvOdEVm7Lgku4y9EgSNlNi+QVbGFkzQ788AsiMHHULacHZRT9w== marius@meinlinuxrechner
(hier eine stark gekürzte Fassung, Eurer muß komplett da rein)
Nun noch die Rechte von der Datei ändern:
[webdemode@s113 .ssh]$ ls -la total 10 drwx------ 2 webdemode webdemode 4096 Mär 31 11:03 . drwxr-x--- 4 webdemode services 4096 Mär 31 10:09 .. -rw-rw-r-- 1 webdemode webdemode 1435 Mär 31 11:03 authorized_keys2 [webdemode@s113 .ssh]$ chmod 644 authorized_keys2 [webdemode@s113 .ssh]$
Das wars. Ab jetzt kann man mit seinem Key einloggen :
[webdemode@s113 .ssh]$ exit Abgemeldet Connection to webdemo.de closed. [marius@eve ~]$ ssh webdemode@webdemo.de Last login: Sat Mar 31 12:39:39 2018 from 79.239.240.108
Damit man sich seinen Webspace per SSH direkt in seinen Arbeitsbereich auf dem Desktop mounten kann, möglichst ohne dauernd Passwörter eingeben zu müssen, braucht man einen SSH-Agent z.b. den Gnome-Keyringdämonen. Diesem gebe ich meinen Key und statt mich jedesmal zu fragen, schickt der Agent dann einfach den Schlüssel an den Server.
ssh-add /pfad/zu/meinem/SSH-Schlüssel_rsa
ggf. Passwort eingeben.
sshfs webdemode@webdemo.de:/home/webdemode/ mnt
und schon kann man im Filesystem seines Desktops einfach auf den Webserver zugreifen, als wenn es Lokal wäre :
[marius@eve ~]$ ls -la mnt/ insgesamt 52 drwxr-x---. 1 testuser 500 4096 31. Mär 12:09 . drwx------. 106 marius marius 20480 31. Mär 11:57 .. -rw-------. 1 testuser testuser 356 31. Mär 13:05 .bash_history -rw-r--r--. 1 testuser testuser 18 8. Aug 2017 .bash_logout -rw-r--r--. 1 testuser testuser 193 8. Aug 2017 .bash_profile -rw-r--r--. 1 testuser testuser 231 8. Aug 2017 .bashrc drwxr-xr-x. 1 testuser testuser 4096 31. Mär 11:59 public_html drwx------. 1 testuser testuser 4096 31. Mär 13:03 .ssh
Welcher User einem da jetzt angezeigt wird, hängt von Eurem System ab, aber i.d.R. werden es nur die UID und GID des Serverusers sein. SSH kümmert sich dabei um alles, also auch, daß man die UID transponiert wird, es gibt am Ende also keine Probleme mit dem Lesen oder Schreiben von Dateien.
Das kann man dann einfach mit Gedit oder einem anderen Programm öffnen (BlueFish z.b. ):
Datei des Webservers in GEdit