Version 1.9.1. – Backup auf ext. SD, autom. Linux-Updates und Remotezugriff


Startseite Foren Installation Version 1.9.1. – Backup auf ext. SD, autom. Linux-Updates und Remotezugriff

Dieses Thema enthält 2 Antworten und 2 Teilnehmer. Es wurde zuletzt aktualisiert von  hannomag vor 2 Wochen, 5 Tagen.

Ansicht von 3 Beiträgen - 1 bis 3 (von insgesamt 3)
  • Autor
    Beiträge
  • #2652

    hannomag
    Teilnehmer

    Zunächst vorab: Dies ist tatsächlich mein erster Eintrag in einem Forum überhaupt. Er ist also sicherlich gewöhnungsbedürftig und nicht sonderlich gut formatiert. Soviel dazu.
    Da ich aber bisher keinen Beitrag zu diesem tollen Projekt geleistet habe, möchte ich meine Konfiguration für einen echten und zumindest im Rahmen meiner Möglichkeiten abgesicherten Remotezugriff auf den j-lawyer-server 1.9.1. mit euch teilen.

    J-Lawyer 1.9.1. auf Odroid-C2 (debian-stretch) mit Backup auf externer SD-Karte, automatischen Betriebssytemupdates und Remotezugriff

    Setup:

    Server: odroid-C2 (debian stretch)
    Client(s): Windows 10
    Smartphone: Android
    Router: FRITZ!box 6490

    Software: j-lawyer-server 1.9.1. (Linux), j-lawyer-client 1.9.1. (Windows) Win32DiskImager (Windows), SmarTTY
    (Windows), Cx File Explorer (Android), Terminus (Android), unattended-update (linux)

    A. Was wird eingerichtet?

    – j-lawyer 1.9.1.

    – Backup auf externer SD-Karte
    – Remotezugriff

    – j-lawyer Server (mit debian stretch)

    – automatische Updates
    – Automount beim Booten für Externe SD-Karte
    – SSH Remotezugriff

    – Remoteterminal
    – geänderten Zugangsport
    – kein Remotezugriff für root
    – Remotezugriff nur für definierte(n) sudo-User
    – Limit für Anmeldeversuche

    – j-lawyer Client (Windows 10)

    – Remotezugang zur Konsole via smarTTY
    – Filebrowser via smarTTY (mit up- und download von Dateien)

    – Zugang Mobilgerät (Android)

    – Remotezugang zur Konsole
    – Remote-Filebrowser

    Achtung:

    Für diese Anleitung wird keine Gewähr übernommen. Es wird auch nicht behauptet, dass die Anleitung vollständig ist. Wer an seinem Server rumspielt, muss selber wissen, was er tut. Hier genannte Programme sind lediglich die Programme, Dienstanbieter und Hersteller, die ich benutzt habe bzw. von denen meine Hardware ist oder deren Betriebssystem bei mir installiert ist. Es gibt i.d.R. immer Konkurrenzprodukte, die ggf. auch besser sind. Aber die habe ich nicht, kenne ich nicht oder ich kann sie schlicht nicht bedienen. Ihr wisst, was ich meine.

    Absolute Sicherheit vor Hackerangriffen über das Internet gibt es nur, wenn das Netzwerk, in dem sich der Server befindet, nicht mit dem Internet verbunden ist. Dann muss aber auch auf den Remotezugriff verzichtet werden. Sobald ein Server mit dem Internet verbunden ist, kann er auch gehackt werden. Sonst würden ja auch keine Mails von amerikanischen Präsidentschaftskandidatinnen gestohlen, keine Studenten in das Netzwerk des Pentagons vordringen und die Chinesen hätten vermutlich auch keine Tarnkappen-Flugzeuge.

    Die Konfiguration nach dieser Anleitung dient lediglich dazu, es den bösen Buben schwerer zu machen und den Remotezugang soweit abzusichern, dass es einen gewissen Aufwand erfordert, unbefugt auf den Server zu gelangen.
    Man kann einen Server nach meinem Kenntnisstand halt nicht völlig absichern. Man kann ihn nur „sicherer“ machen.

    Natürlich kann man den Server auch noch stärker absichern (z.B. durch erstellen einer Blacklist etc.), mit dieser Konfiguration sollte aber wohl ein erforderliches Mindestmaß an Sicherheit gewährleistet sein.

    Sollte jemand Verbesserungsvorschläge haben, immer her damit. Denn ein Mehr an Sicherheit ist natürlich immer besser. Aber mit meinem autodidaktischen Selbststudiums-crashkurs zu Dynamic-DNS-Services, SSH Zugängen und deren Absicherung unter Linux, der Konfiguration des Server-Betriebssystems sowie der Konfiguration von j-lawyer letztes Wochenende, bin ich nur bis hier gekommen. Also habt bitte Nachsicht mit mir.

    Soll ein vorhandener Server anhand dieser Anleitung mit Remotezugang versehen und abgesichert werden (dann natürlich ohne das System neu aufzuspielen), ist es zwingend empfohlen, vorher zumindest ein Image der bestehenden Konfiguration zu speichern. Am besten arbeitet man mit einer Kopie der bestehenden Konfiguration. Dann kann man bei Problemen einfach wieder zur alten Konfiguration zurückkehren.
    Denn ansonsten kann die Wiederherstellung der alten Konfiguration und der Daten zumindest anstrengend, wenn nicht gar sehr kompliziert werden.

    Es wird ferner empfohlen, vor der Bearbeitung von Dateien (z.B. der /etc/sshd_config) immer eine Sicherheitskopie der zu bearbeitenden Datei anzulegen, wobei darauf zu achten ist, dass die Dateiberechtigungen sich nicht ändern.

    Es gibt bei der Einrichtung unter Verwendung eines Remote-Terminals wie PuTTY oder smarTTY auch an verschiedenen Stellen der Einrichtung die Möglichkeit, sich aus dem Server auszusperren, da man zur Absicherung des Zugangs gewisse Ports ändert, dem User root den Remotezugriff verbietet und man schon durch Tippfehler oder ähnliches einfach über viele Fallstricke fallen kann. Deshalb sollte man sicherheitshalber eine Tastatur und einen Monitor haben, die man zur Not an den den Server (also den odroid) stöpseln kann, um etwaige Fehler zu korrigieren, ohne dass man wieder von vorne anfangen muss. Sonst bringt die Einrichtung des Remotezugriffs ein gewisses Frustpotential mit sich.
    Ich habe zwischendurch sogar das ganze Image des Servers gesichert, um einen Fallback-Punkt zu haben. Da man dafür aber immer wieder den Server runter fahren muss, um an die System-Karte zu kommen, besteht auch hier die Gefahr sich auszusperren, wenn man nicht weiß was man tut. Denn ob man sich ausgesperrt hat, weil man eine bestimmte Einstellung hätte sofort nach einer anderen vornehmen müssen, merkt man halt erst, wenn der Server wieder am Strom hängt und man sich einloggen will. Ich kann da ein Liedchen von singen.

    Die Konfiguration des Servers kann also auch am Server direkt vorgenommen werden, wenn dieser mit einem Monitor und einer Tastatur verbunden ist. Man kann den Server aber auch über ein Programm von einem anderen Rechner aus zu konfigurieren. So habe ich das gemacht, da auch ein Webbrowser für die Einrichtung des Dynamischen-DNS-Services und die Konfiguration des Routers benötigt wird und man so nicht von Tastatur zu Tastatur springen muss. Die Konfiguration des Servers mit eigener Tastatur und eigenem Monitor verringert aber sicherlich das oben beschriebene Frustpotential. Um den Server später per Remotezugriff warten zu können, wird ein solches Programm für den Remotezugriff auf das Terminal auf dem Computer, von dem aus die Remotewartung erfolgen soll (z.B. Notebook) aber ohnehin benötigt.
    Meine Wahl ist das Programm smarTTY, da es über ein Smartterminal mit Filebrowser verfügt und einzelne Dateien oder Verzeichnisse vom Server heruntergeladen oder auf diesen hochgeladen werden können.
    Die Anleitung bezieht sich auf die Nutzung des Programms smarTTY, es kann aber auch jedes andere Programm, das eine Remoteverbindung mit Konsolenbedienung zum Server aufbauen kann (z.B. PuTTY), verwendet werden.

    B. Anleitung

    Sofern die Konfiguration am Server vorgenommen wird, ist der jeweilige Punkt mit (Server) gekennzeichnet. Man erkennt es aber in der Regel auch daran, dass mit der Linux-Konsole gearbeitet wird. Alles wofür man einen Browser braucht, habe ich mit Windows 10 gemacht und ist mit (Win) gekennzeichnet. Das sollte bei iOS oder Linux mit Benutzeroberfläche aber auch funktionieren. Was auf dem Smartphone einzustellen ist, ist mit (Android) gekennzeichnet.

    I. Aufsetzen und Einrichten des Servers (auf dem odroidC2)

    1. debian Image herunterladen und mit Win32diskImager flashen

    download:

    https://oph.mdrjr.net/meveric/images/Stretch/Debian-Stretch64-1.0-20180202-C2.img.xz

    Anleitung für Installation des Images:

    https://forum.odroid.com/viewtopic.php?f=138&t=27449

    Standard-User: root
    Standardpasswort: odroid

    Das Passwort für den User root ändern wir am Ende der Einrichtung und bevor wir den Server von außen erreichbar machen, um den Zugang abzusichern. Für die Einrichtung kann es zunächst so bleiben, da ja ein sicheres Passwort gewählt werden sollte (mindestens 15 Zeichen mit Groß- und Kleinbuchstaben, Zahlen und Sonderzeichen). Nach eigener Erfahrung nervt es aber, wenn man schon bei der Konfiguration ein solches Sicheres Passwort nutzt, sollte man danach gefragt werden.

    Geändert wir das Passwort des Users root dann mit:

    # passwd root

    Wenn ihr das als User root macht und

    # sudo passwd root

    wenn ihr später als „nicht-root“ User (den legen wir im Laufe der Prozedur an) macht.

    2. smarTTY oder das entsprechende Programm deiner Wahl installieren (Win)

    Google hilft da weiter.

    3. Automatische Updates mit unattended-updates für debian einrichten (Server)

    aa. Softwarepakete für unattended-upgrades installieren

    # apt-get install unattended-upgrades

    bb. Konfiguration von unattended-upgrades

    # nano /etc/apt/apt.conf.d/50unattended-upgrades

    Unattended-Upgrade::Origins-Pattern {
    // Codename based matching:
    // This will follow the migration of a release through different
    // archives (e.g. from testing to stable and later oldstable).
    „o=Debian,n=jessie“;
    „o=Debian,n=jessie-updates“;
    // „o=Debian,n=jessie-proposed-updates“;
    // „o=Debian,n=jessie,l=Debian-Security“;

    // Archive or Suite based matching:
    // Note that this will silently match a different release after
    // migration to the specified archive (e.g. testing becomes the
    // new stable).
    „o=Debian,a=stable“;
    „o=Debian,a=stable-updates“;
    // „o=Debian,a=proposed-updates“;
    „origin=Debian,codename=${distro_codename},label=Debian-Security“;
    };

    und

    // Automatically reboot *WITHOUT CONFIRMATION* if
    // the file /var/run/reboot-required is found after the upgrade
    Unattended-Upgrade::Automatic-Reboot „true“;

    // Automatically reboot even if there are users currently logged in.
    Unattended-Upgrade::Automatic-Reboot-WithUsers „false“;

    // If automatic reboot is enabled and needed, reboot at the specific
    // time instead of immediately
    // Default: „now“
    Unattended-Upgrade::Automatic-Reboot-Time „04:00“;

    // Use apt bandwidth limit feature, this example limits the download
    // speed to 70kb/sec
    Acquire::http::Dl-Limit „1024“;

    Anschließend speichern wir die geänderte Datei mit der Tastenkombination Strg+O und schließen sie mit Strg+X.
    Alternativ kann auch direkt die Tastenkombination Strg+X verwendet werden. Dann muss allerdings noch vor dem
    Verlassen bestätigt werden, dass die Datei gespeichert werden soll (mit der Taste Y bestätigen) und der Dateiname
    durch Betätigung der Eingabetaste bestätigt werden.

    cc. Aktivieren der automatischen Upgrades durch Erstellung der Konfigurationsdatei /etc/apt/apt.conf.d/20auto-upgrades

    automatisch: # dpkg-reconfigure -plow unattended-upgrades

    manuell: # nano /etc/apt/apt.conf.d/20auto-upgrades

    Inhalt der Konfigurationsdatei:

    APT::Periodic::Update-Package-Lists „1“;
    APT::Periodic::Unattended-Upgrade „1“;

    Anpassung der Datei /etc/apt/listchanges.conf

    # nano /etc/apt/listchanges.conf

    und folgendes eintragen:

    [apt]
    frontend=none # Werte: pager|browser|text|mail|none
    email_address=root
    confirm=1
    save_seen=/var/lib/apt/listchanges.db
    which=news # Werte: news|changelogs|both

    Anschließend speichern wir die geänderte Datei mit der Tastenkombination Strg+O und schließen sie mit Strg+X.
    Testmöglichkeit für die Konfiguration

    # unattended-upgrades -v –dry-run # Verbose + Dry Run

    und

    # unattended-upgrades -d -v –dry-run # Debug + Verbose + Dry Run

    3. externe SD-Karte (für Backups) beim Start mittels fstab automatisch einbinden (Server)

    Um die SD-Karte bei bedarf problemlos an einem Windows-PC lesen und beschreiben zu können, das Dateisystem FAT bzw. exFat auf der SD-Karte verwenden(je nach Größe der SD-Karte, bei exFAT (SD-Karte größer als 32gb) muss ggf. mittels

    # apt-get install exfat-fuse exfat-utils

    die Unterstützung des Dateisystem installiert werden.

    Diese Anleitung bezieht sich nur auf SD-Karten, die das FAT-Dateisystem verwenden. Wird ein anderes Dateisystem genutzt, muss die Konfiguration entsprechend angepasst werden.

    a. Kartenleser per USB mit an den Odroidc2 anschließen und im FAT- oder exFat-Dateisystem formatierte SD-Karte
    einstecken.
    b. Mountverzeichnis erstellen (z.B. unter /mnt)

    # mkdir /mnt/extSD

    c. Werte des Datenträgers ermitteln (wichtig ist die UUID).

    # blkid

    und

    # lsblk

    liefern die erforderlichen Informationen. Im Beispiel verwende ich die UUID 9999-8888. Diese muss mit der ermittelten UUID der verwendeten Karte ersetzt werden.

    d. Beim Bootvorgang zu mountenden Datenträger in der /etc/fstab eintragen

    # nano /etc/fstab

    und um die folgende Zeile mit der ermittelten UUID und dem Mountverzeichnis ergänzen (zwischen den Werten mindestens einen Tabulator Abstand einfügen):

    UUID=9999-8888 /mnt/extSD vfat auto,nofail,sync,users,rw,umask=000 0 2

    Anschließend speichern wir die geänderte Datei mit der Tastenkombination Strg+O und schließen sie mit Strg+X.

    ACHTUNG: wird die SD-Karte formatiert oder eine andere SD-Karte verwendet, ändert sich die UUID und die neu formatierte bzw. neue SD-Karte muss der Eintrag in der fstab angepasst werden!

    Jetzt kann man das Laufwerk bzw. das Dateisystem manuell einhängen/mounten.

    # sudo mount -a

    Dabei prüft man, ob man den Eintrag in der Datei „/etc/fstab“ korrekt angelegt hat. Mit „# df -h“ und „# lsblk“ kann man prüfen ob und wo (Mount-Point) das eingehängt wurde. Nach einem Reboot sollte das Laufwerk automatisch eingebunden sein.

    4. j-lawyer-server / j-lawyer-client installieren (Server / Win)

    Wer auf diese Anleitung gestoßen ist, sollte wissen wie er das macht und wo er die erforderlichen Dateien herunterladen kann. Ganz heißer Tipp, auf http://www.j-lawyer.org müsste man alles dazu finden. 😉

    II. Einrichtung Konfiguration des SSH-Remote-Zugangs

    1. „Nicht-root“ User anlegen und konfigurieren (Server)

    Damit wir den Zugang von außen für den User root sperren können, ihr euch dadurch aber nicht aussperrt, legen wir einen neuen Benutzer an, der mittels dem Befehl „sudo“ auch administrative Rechte erhalten kann. Das machen wir, da der Benutzername root als Standardname für potentielle Angreifer leicht zu erraten ist und ein Eindringling dann auch noch mit Rootrechten ausgestattet in eurem Server wüten könnte. Im Beispiel nennen wir den User „anwalt“.

    a. User anlegen (Server)

    # adduser -m anwalt

    (Das -m legt automatisch ein Homeverzeichnis für den User unter /home an, im Beispiel wäre das /home/anwalt)

    Jetzt legen wir das Passwort für den User „anwalt“ fest, fügen ihn zu den Gruppen „users“ und „sudo“ hinzu und legen die Standardshell für den neuen User fest.

    b. Passwort festlegen (Server)

    # passwwd anwalt

    eingeben und anschließend das gewünschte Passwort festlegen. Das Passwort sollte natürlich entsprechend sicher sein. Ich nehme mindestens 15 Zeichen mit Groß- und Kleinbuchstaben, Zahlen und Sonderzeichen, also kein Passwort, das sich mittels einer Wortliste ermitteln lässt (Bsp.: 4711_Echt_+_Koelnisch_+_Wasser_+_Idefix-2018).

    c. Den Benutzer der Gruppe „sudo“ (als Hauptgruppe) hinzufügen (Server)

    Wir fügen den neuen Benutzer der Gruppe „sudo“ hinzu, damit dieser über „sudo“ Administratorenrechte erhalten kann. Das benötigen wir z.B. dafür, um den Server per Remote neu zu starten (das geht dann mittels # sudo reboot), falls das nötig ist. Sie müssen nicht für jeden j-lawyer-Benutzer einen User anlegen, da der j-lawyer-Zugang unabhängig davon funktioniert, ob ein entsprechender User auf dem Server existiert. Sie sollten nur für die Personen einen User auf dem Server anlegen, die Administratorenrechte haben sollen, denn z.B. eine studentische Hilfskraft soll ja nicht auf dem Server rumspielen oder die Verzeichnisse durchforsten können.

    Dafür geben wir in der Konsole folgendes ein:

    # usermod -a -g sudo anwalt

    d. Standardshell für den neuen User festlegen (Server)

    # usermod -s /bin/bash anwalt

    e. Neuen User-Account testen (Server)

    Mit

    # su anwalt

    wechseln wir zu dem User „anwalt“. Um sicher zu gehen, dass das geklappt hat, können wir mit

    # whoami

    prüfen, ob wir erfolgreich zum User anwalt gewechselt haben. Mit

    # id anwalt

    prüfen wir die Gruppenzugehörigkeit des Users. Die Ausgabe sollte dann z.B. so aussehen:

    uid=1000(anwalt) gid=27(sudo) groups=27(sudo)

    Hat das geklappt, wechseln wir mit

    # exit

    zum User root zurück.

    2. Einstellungen für den Remotezugang konfigurieren (Server)

    ACHTUNG: Ab hier kann man sich bei der Einrichtung mittels PuTTY oder smarTTY aussperren, da wir dem User root den Zugang mittels SSH verweigern werden! Am besten sichert man den Stand jetzt mittels Win32DiskImager als Image, dass man zur Not einfach wieder aufspielen kann.

    Jetzt sorgen wir dafür, dass der Remotezugang nicht mehr über den Standardport für ssh, also nicht mehr über den Port 22, möglich ist und dem User root kein Remotezugang zum Server mehr gewährt wird. Im Beispiel wählen wir den Port 5000. Zudem legen wir die Nutzer fest (im Beispiel der User „anwalt“), denen der Remotezugang zum Server via Terminal gewährt wird (die j-lawyer-Benutzer sind hiervon unabhängig), begrenzen die zulässige Anzahl der Anmeldeversuche (im Beispiel auf 3) und der parallelen Sessions (im Beispiel auf 4). Dafür müssen wir die Datei sshd_config im Verzeichnis /etc/ssh/ editieren.

    Dazu geben wir

    # nano /etc/ssh/sshd_config

    im Terminal ein und passen die Einträge entsprechend an.

    Port 5000 #der Port, über den der bzw. die weiter unten unter AllowUsers
    #eingetragenen User per Remote auf den Server mittels Konsole
    #zugegriffen werden kann. Diesen müssen wir später noch im
    #Router eintragen. Auch das Remoteprogramm wie SmarTTY oder
    #PuTTY funktioniert danach spätestens ab dem nächsten reboot
    #des Servers nur noch, wenn man den neuen Port eingibt. Bei
    #SmarTTY kann man einfach den Port hinter die ip_Adresse (bzw.
    #später den Hostnamen) des servers den Port mit Doppelpunkt
    #getrennt anfügen (Bsp. 192.168.0.1:5000 bzw. später dann
    #beispiel.spdyn.org:80)
    #AddressFamily any
    #ListenAddress 0.0.0.0
    #ListenAddress ::
    #HostKey /etc/ssh/ssh_host_rsa_key
    #HostKey /etc/ssh/ssh_host_ecdsa_key
    #HostKey /etc/ssh/ssh_host_ed25519_key

    # Ciphers and keying
    #RekeyLimit default none

    # Logging
    #SyslogFacility AUTH
    #LogLevel INFO

    # Authentication:

    #LoginGraceTime 2m
    PermitRootLogin no #der User root ausgesperrt
    AllowUsers anwalt #nur der User Anwalt wird zugelassen. Weitere User können mit
    #Komma getrennt hinzugefügt werden (z.B.anwalt,anwalt2,anwalt3)
    #StrictModes yes
    MaxAuthTries 3 #maximale Anmeldeversuche = 3
    MaxSessions 4 #maximale parellele Sessions = 4

    Nachdem die Änderungen eingetragen worden sind, speichern wir die geänderte Datei mit der Tastenkombination Strg+O und schließen sie mit Strg+X.

    Ab jetzt hat spätestens nach einem Neustart des Servers nur noch der User anwalt per SSH-Zugang zur Konsole des Servers. Ab jetzt müsst ihr nach einem Neustart des Servers auch bei PuTTY usw. den neuen Port angeben (hier 5000).

    3. Dynamische IP-Adresse über einen Dynamic-DNS-Service dauerhaft erreichbar machen (Win)

    Ich habe hierfür den kostenlosen Anbieter Securepoint (spDyn) verwendet. Es sollte aber auch mit jedem anderen Anbieter eines Dynamic-DNS-Service funktionieren. Von Anbieter zu Anbieter ist jedoch ,neben der unterschiedlichen Einrichtung des Accounts und des Hosts, der Benutzername und das Passwort für den DynDNS-Service sowie die Update-URL und natürlich die Domainbezeichnung im Hostnamen unterschiedlich. Diese Informationen braucht ihr, da diese für die Aktivierung des DynDNS-Service im Router erforderlich sind. Also diese Angaben bitte notieren.

    a. Erstellen eines Accounts bei einem Dynamic-DNS-Service.

    Hier wird im Beispiel der Anbieter Securepoint verwendet (https://spdyn.de/). Jeder andere sollte aber auch gehen.

    aa. Einen IPv4-Host hinzufügen und den Hostnamen notieren (den nennen wir hier mal beispiel.spdyn.org). Dazu benötigt
    ihr eure aktuelle IP-Adresse. Diese findet ihr entweder in der Internet-Übersicht eures Routers oder mittels
    wieistmeineip.de heraus. Ist der Dynamic-DNS-Service eingerichtet, teilt euer Router dem Service die neue IP-
    Adresse, unter der der Server angesprochen werden kann, automatisch mit, sobald der Internetprovider eine neue IP-
    Adresse für euren Internetanschluss vergibt und der Anschluss bleibt über dem Hostnamen erreichbar (Das ist ja der
    Sinn des Dynamic-DNS-Service ;))

    bb. Updatetoken aktivieren und generieren (Den Updatetoken unbedingt notieren, da dieser noch im Router eingetragen
    werden muss. Dazu weiter unten im Abschnitt Router konfigurieren).

    b. Konfiguration des Routers (Win)

    Hier wird der Router am Beispiel einer Fritz!Box für einen Host bei Securepoint mit dem Hostnamen beispiel.spdyn.org konfiguriert. Die erforderliche Konfiguration kann (bzw. wird wohl) bei anderen Routern abweichen. Wir rufen die Benutzeroberfläche des Routers auf. Dazu geben wir

    fritz.box

    in die Adresszeile des Browser ein, bestätigen die Adresse durch Betätigung der Eingabetaste und loggen uns anschließend im Router ein.

    aa. Feste IP-Adresse im Netzwerk

    Zunächst weisen wir den Router an, dass er dem Server im Netzwerk selber immer die gleiche IP-Adresse zuweist. Dazu
    wählen wir im Auswahlmenü den Punkt „Heimnetz“ und klicken beim Server (das oben genannte debian-Image nennt diesen
    als Standard odroid-stretch64) auf Details. Anschließend setzen wir das Häkchen bei „Diesem Gerät immer die gleiche
    IPv4-Adresse zuweisen.“. Dann noch mit „OK“ bestätigen und der Server erhält danach vom Router im Netzwerk immer
    die selbe IP-Adresse.

    bb. Portfreigaben

    Anschließend navigieren wir im Navigationsmenü (auf der linken Seite) zu dem Punkt „Internet“ und dort den Punkt
    „Freigaben“. Hier sagen wir dem Router, an welchem Port er „lauschen“, also für den Zugriff von außen offen sein
    soll. Dazu wählen wir den Reiter „Portfreigaben“, sofern dieser nicht bereits angezeigt wird. Wir klicken auf
    „Gerät für Freigaben hinzufügen“ und wählen im Dropdown-Menü den Server aus (hier im Beispiel heißt der ja
    odroid-stretch64). Alternativ können wir auch die IPv4-Adresse angeben.

    Jetzt klicken wir auf „neue Freigabe“ und wählen als Anwendung „Andere Anwendung“ aus und benennen die Freigabe.
    Hier nennen wir Sie mal Remotezugang. Als Protokoll wählen wir „TCP“. Bei „Port an Gerät“ tragen wir in beide
    Kästchen den Port ein, über den man den j-lawyer-server erreicht. Standardmäßig ist das 8080. Konfiguriert man den
    j-lawyer-server so, dass ein anderer Port verwendet wird, dann müssen wir natürlich den anderen Port eintragen. Bei
    „Port extern gewünscht“ tragen wir ebenfalls den Port ein, über den man den j-lawyer-server erreicht. Also als
    Standard die 8080. Bei mir füllen sich die anderen Kästchen automatisch, wenn man den Port in das erste Kästchen
    einträgt. Ist das bei euch nicht so, dann also per Hand die anderen Kästchen füllen. Die übrigen Einstellungen
    kann man so behalten (Freigabe aktivieren und Internetzugriff über IPv4 und IPv6) und mit „OK“ bestätigen.

    Danach klicken wir nochmal auf „neue Freigabe“ und wählen als Anwendung wieder „Andere Anwendung“ aus. Diese
    Freigabe benennen wir hier mal j-lawyer-server. Als Protokoll wählen wir erneut „TCP“. Bei „Port an Gerät“ tragen
    wir in beide Kästchen den Port ein, den wir in der Datei /etc/ssh/sshd_config angegeben haben, ein. Hier im
    Beispiel ist das der Port 5000. Bei „Port extern gewünscht“ tragen wir ebenfalls 5000 ein. Die übrigen
    Einstellungen kann man wieder so behalten und mit „OK“ bestätigen.

    Anschließend klicken wir nochmal unten auf „OK“, um die neuen Freigaben zu speichern und zu aktivieren. Danach noch
    auf „Übernehmen“ und die Freigaben sollten mit grünen Punkten markiert werden.
    Es gibt hier im Forum zwar eine Anleitung, wonach man angeblich nur eine Freigabe braucht, meine Erfahrung ist aber
    eine andere. Wenn ich mich da irre, dann berichtigt mich bitte.

    cc. Dynamischen-DNS-Service am Router einrichten

    Nun wählen wir wieder „Internet“ und dort erneut „Freigaben“ aus. Dort öffnen wir die Registerkarte „DynDNS“ und
    setzen das Häkchen bei DynDNS benutzen. Als DynDns-Anbieter wählen wir bei dem Beispiel spDyn „Benutzerdefiniert“
    aus. Das Feld für die „Update-URL“ füllen wir mit der vom gewählten Anbieter des Dynamic-DNS-Service angegebenen
    Update-URL. Im Falle von Securepoint ist das:

    https://update.spdyn.de/nic/update?hostname=<domain>&myip=<ipaddr&gt;

    Die update-URL auch genau so einfügen, wie der Anbieter sie zur Verfügung stellt, und nicht verändern.
    Als „Dominname“ geben wir den Hostnamen ein, den wir beim Anbieter des Dynamische-DNS-Service definiert haben.
    Im Beispiel ist das beispiel@spdyn.org. Der Benutzername ist bei Securepoint ebenfalls der Hostname, also im
    Beispiel beispiel@spdyn.org. Der Benutzername ist aber wohl nicht bei allen Anbietern eines Dynamische-DNS-Service
    der Name de Hosts. Den Benutzernamen kann man aber über sein Benutzerkonto bei dem jeweiligen Anbieter in Erfahrung
    bringen.

    Als Passwort gebt ihr im Falle von Securepoint den Token ein, den ihr bei der Einrichtung des DynDNS-Service
    angefordert und euch hoffentlich notiert haben. Ansonsten kann man auch einen neuen generieren lassen und dann
    diesen einfügen. Bei anderen Anbietern kann das Passwort auch zur Verfügung gestellt werden, ohne das man einen
    Token generieren muss. Das variiert von Anbieter zu Anbieter.

    Jetzt noch mit „Übernehmen“ bestätigen und die Einrichtung des Routers ist fertig.

    c. Abschließende Konfiguration des j-lawyer Clients (Win)

    Wenn der DynDNS-Service im Router eingerichtet ist und läuft, muss im Anmeldefenster beim j-lawyer Client unter dem Reiter „Verbindung“ bei „Server“ noch der Hostname eingetragen werden. Hier im Beispiel also beispiel.spdyn.org. Den Server speichert der j-lawyer Client nach dem ersten erfolgreichen Login als Standard.
    Damit sollte alles eingerichtet und der Remotezugriff funktionieren. Ich habe das getestet, indem ich einen Hotspot mit meinem Handy eingerichtet habe und mit meinem Notebook über diesen Hotspotzugang auf den Rechner im Büronetzwerk zugegriffen habe.

    Bei der Anmeldung mit dem j-lawyer Client werden die Knöpfe für das Prüfen des Server-Status usw. (Reiter j-lawxer-box) nicht mehr funktionieren, da wir den root ja ausgesperrt haben. Hierfür muss man jetzt SmarTTY (oder PuTTY o.ä) verwenden und sich mit dem erstellten „Nicht-root“ User (hier im Beispiel der User anwalt) anmelden. Den in der Dokumentation (Seite 5 oder 6) angegebenen Befehlen, um den Server zu starten, zu stoppen oder dessen Status zu prüfen, muss dann ein „sudo“ vorangestellt werden.

    d. Externe SD-Karte für die Backups

    Ist man bei j-lawyer als Benutzer mit den entsprechenden Rechten angemeldet, muss in den Datensicherungseinstellungen im Reiter „Synchronisation“ noch die externe SD-Karte als Speicherort angegeben werden. Dafür klickt man auf die drei Pünktchen zur Auswahl des Synchronisationsziels. In dem neuen Fenster wählt man „Lokaler Ordner“ aus und gibt in dem Feld „Ordner“ den Ordner an, in dem die externe SD-Karte eingehängt ist. Hier im Beispiel ist die externe SD-Karte unter /mnt/extSD eingehängt, was auch genau so (den „/“ am Anfang nicht vergessen) eintragen. Die restlichen Felder bleiben frei. Danach noch auf „Übernehmen“ und anschließend auf „Speichern“ klicken.
    Ich habe auch direkt für den HTML-Export einen Zielordner auf der externen SD-Karte angelegt und bei j-lawyer eingerichtet. Dadurch kann auch ohne dass es eine j-lawyer-app gibt, mit dem Smartphone oder Tablet problemlos auf den Inhalt der Akten zugegriffen werden.

    e. Fernzugriff per Smartphone (Android/Server/Win)

    Ich bin kein Apfelkind, deswegen erkläre ich das anhand eines Android-Smartphones bzw. Tablets. Entsprechende Apps gibt es aber bestimmt auch für das Konkurrenzprodukt mit dem Apfel.

    aa. Zunächst müsst ihr bei den Datensicherungseinstellungen den HTML-Export eingerichtet haben. Ich habe dafür auf der
    externen SD-Karte einen eigenen Ordner angelegt und diesen als Zielordner für den HTML-Export angegeben.

    Kurz:

    In der Konsole anmelden (Server) und

    # sudo mkdir /mnt/extSD/html

    eingeben. Ist man noch als User root unterwegs, kann man „sudo“ weglassen.

    bb. Dann mit dem j-lawyer Client (Win) in den Einstellungen für die Datensicherung im Reiter HTML-Export den Zielordner
    (hier /mnt/extSD/html) angeben und speichern. Mit der nächsten Datensicherung wird nun der HTML-Export dort
    gespeichert.

    cc. Ab jetzt (Android). Jetzt installiert man auf dem Smartphone/Tablet einen Filebrowser, mit dem
    man mit SFTP auf den Server zugreifen kann, z.B. Der Cx File Explorer, an dessen Beispiel es hier
    erklärt wird. Den gibt es neben vielen anderen Programmen, die das auch können, im Play Store.

    Startet den File Explorer auf dem Smartphone und wählt den Reiter „NETWORK“. Dort auf das „+“ im blauen Kreis
    tippen und im neuen Fenster den Reiter „Remote“ wählen. Dort wiederum „SFTP“ antippen. Jetzt gibt man unter Host die
    Adresse des Hosts ein (hier beispiel.spdyn.org) und unter Port den Zugangsport für die Remotekonsole (hier 5000).
    Man wählt https, gibt den Usernamen des „nicht-root“ Users an (hier anwalt) und gibt das Passwort den Users ein.
    Anschließend auf „ok“ und man kann durch das Dateisystem des servers navigieren und die einzelnen Dateien aufrufen.
    Eben auch die in dem Ordner /mnt/extSD/html. Dort findet ihr unter den bekannten Aktenzeichen die jeweiligen
    Dokumente finden und auf dem Smartphone/Tablet öffnen.

    Die Remotekonsole des Servers erreicht ihr mit dem Smartphone mittels einer Terminal-App wie z.B. Terminus. Da auf
    das „+“ im grünen Punkt tippen, new „New host“ wählen und den Hostnamen eintragen. Dann dann bei SSH/Mosch das
    Häkchen setzen (aber dann nicht in der erweiterten Ansicht das Häkchen auch noch bei Mosh setzen). Den Port, den
    Usernamen und das Passwort des Users eingeben (hier also insgesamt beispiel.spdyn.org, 5000, anwalt und
    [dasPasswortvomUseranwalt]). Und schon kommt Ihr vom Smartphone aus per Remote auf die Konsole des Servers.

    So, jetzt wisst ihr, wie ich mein letztes Wochenende verbracht habe …viel Spaß damit!

    Quellen, aus denen ich neben einer ganzen Menge „learning by doing“- diese Anleitung zusammengestellt habe:

    Autoupdate:
    https://otremba.net/wiki/Automatische_Updates_(Debian))

    Automount der externen SD-Karte:
    https://www.elektronik-kompendium.de/sites/raspberry-pi/2012181.htm

    Benutzer anlegen und konfigurieren:
    https://www.elektronik-kompendium.de/sites/raspberry-pi/2007011.htm

    Konfiguration der DynDNS-Freigabe für spDyn
    https://wiki.securepoint.de/SPDyn/Hostverwenden

    und natürlich für alles im Zusammenhang mit J-lawyer.og
    https://www.j-lawyer.org

    #2653

    j-lawyer.org
    Keymaster

    Wow, vielen Dank für die tolle Arbeit!

    Die j-lawyer.BOXen sind ganz ähnlich aufgesetzt. Zusätzlich läuft dort noch ein NTP Client, ein Ajaxterm (das Du wahrscheinlich nicht brauchst) hinter einem lighttpd, ein Sambaserver.

    Für eine bessere Kompatibilität mit macOS-Clients noch avahi-daemon und libnss-mdns.

    Und das System ist mit einer Swapdatei (nicht -Partition) aufgesetzt, mit einem Swappiness-Faktor von 10.

    Beste Grüße,
    Jens
    (j-lawyer.org)

    #2654

    hannomag
    Teilnehmer

    Nichts zu danken. Ich danke dir für das Programm j-lawyer!
    Leider sieht man der Anleitung an, dass ich dann doch bereits zu lange vor dem Rechner gesessen habe, als ich sie getippt habe. Ich würde sie deshalb gerne nochmal überarbeiten. Nur funktioniert bei mir der Bearbeiten-Button hier im Forum nicht.

    Der Fehler, der aber am ehesten Verwirrung stiften dürfte, befindet sich unter B.II.1.b.
    Das Passwort für den User anwalt legt man natürlich mit dem Befehl

    # passwd anwalt

    an. Da hat sich ein zweites „w“ eingeschlichen.

    Die anderen, nennen wir sie mal Fehltritte, in der Anleitung, sind mir beim Durchlesen im ausgeschlafen Zustand aber nicht minder unangenehm. Doch wenn ich das diktiert hätte, dann würde jetzt vermutlich jemand eine ganze Weile nicht mehr mit mir reden. 🙂

    Na ja, aller Anfang ist schwer. Die nächste Anleitung wird dann besser und hoffentlich auch kürzer.

    Nochmal vielen Dank für das tolle Programm!

    Beste Grüße

Ansicht von 3 Beiträgen - 1 bis 3 (von insgesamt 3)

Du musst angemeldet sein, um auf dieses Thema antworten zu können.