Ergebnis 1 bis 5 von 5
  1. #1
    VIP Avatar von SpaceRat
    Registriert seit
    12.08.2012
    Ort
    Midgard
    Beiträge
    416
    Thanks
    49
    Thanked 165 Times in 97 Posts

    How-To: Box sicher ins Internet freigeben

    Für viele Besitzer eines Enigma2-Receivers dürfte mit kaufentscheidend gewesen sein, daß man an diesen herrlich viel drehen, basteln und auch fernsteuern kann.

    Gerade im Zeitalter von Smartphones, Phablets, Tablets und Notebooks sind die Möglichkeiten des Fernzugriffs auf die heimische Box reizvoll, insbesondere seitdem auch immer mehr Enigma2-Boxen das Transcoding beherrschen, also einen Sender oder eine Aufnahme so zusammenkomprimieren können, daß sie auch unterwegs auf dem Smartphone ruckelfrei betrachtet werden kann.

    Die Verlockung ist riesengroß, dazu einfach mal im eigenen Router Port 80 für das Web-Interface aufzureißen, damit man von überall auf seine Box zugreifen kann ... das kann dann aber eben dummerweise jeder, auch Leute, die das nicht können sollten.

    Meistens kriegt man zu diesem Thema aber nur
    - entweder gefährliche Ratschläge, wie man sich auf diese Weise in den Fuß schießt
    - oder den Hinweis, es nicht zu tun, um sich nicht in den Fuß zu schießen, allerdings ohne gangbare Alternative

    Deshalb habe ich mich entschlossen, hier einmal ein Tutorial zu schreiben, wie man seine Box sicher ins Netz freigeben kann, denn was die reinen "Warner" gerne vergessen: Nur zuhause auf der Couch Sender durchklitschen kann man mit vielen geschlossenen Receivern besser und stabiler als mit den meisten E2-Boxen.

    Wenn man also eine E2-Box hat, dann will man ihre Möglichkeiten auch nutzen.

    An dieser Stelle ein Warnhinweis:
    Es wäre brandgefährlich, die Sicherheit beim Zugriff auf den E2-Receiver getreu der Devise "Was sollen die schon damit machen, zur Not installier ich halt neu." zu vernachlässigen!

    Wenn Ihr Eure Box unsicher freigebt, dann gefährdet Ihr letztendlich immer sämtliche Eurer Daten, die irgendwo im Heimnetz abgelegt sind, also potentiell auch Kreditkarten- oder Onlinebanking-Informationen.
    Es ist eben nicht nur ein unwichtiger Sat-/Kabel-Receiver, den Ihr preisgebt, sondern ein funktionstüchtiger Linux-Rechner, von dem aus ein erfahrener Angreifer den Rest des Heimnetzes von innen heraus mit gewaltigen Erfolgschancen angreifen kann!
    Geändert von SpaceRat (29.04.2014 um 11:07 Uhr)
    Receiver/TV/PC:
    • Duo² / ATV 5.3 / 4*S2 / 2*C / 1,8TB / Samsung 50" Plasma / Yamaha RX-V 663
    • AX Quadbox HD2400 / 2*S2 / 2*C / 930GB / ATV 5.3
    • 2x Solo² / ATV 5.3
    • DVBSky S-Twin / Samsung SyncMaster T240HD / Intel i7-4771, 32GB, 3,6TB RAID10 int., 57 TB in div. RAID5 ext. / Yamaha RX-V595aRDS
    • TechniSat SkyStar HD2 / Medion 17" (2.PC)
    Alles per Kabel vernetzt

    Pay-TV: Redlight Mega, Brazzers, XXL, HD-, Sky
    Internet: UM 1play 100 / Cisco3212+Linksys WRT1900ACS+F!B7390 / IPv4 (UM)+IPv6 (HE)

  2. The Following 8 Users Say Thank You to SpaceRat For This Useful Post:



  3. #2
    VIP Avatar von SpaceRat
    Registriert seit
    12.08.2012
    Ort
    Midgard
    Beiträge
    416
    Thanks
    49
    Thanked 165 Times in 97 Posts
    Variante 1: Secure Shell/ssh mit (mehreren) Tunnel

    Diese Variante ist sehr sicher und verhältnismäßig einfach einzurichten.
    Die Tatsache, daß die Verbindung nur bedarfsweise hergestellt werden muß und der ssh-Server somit auch nur bedarfsweise läuft, macht diese Methode zum Mittel der Wahl.

    Ich werde die Einrichtung mittels telnet erklären, man könnte zwar das/die Pakete auch per GUI installieren, muß dann aber so oder so auf die shell der Box zugreifen.

    Im weiteren Verlauf werde ich für den Zugriff von außen voraussetzen, daß
    • bereits ein DynDNS-Host für das Heimnetz (IPv4) bzw. die Box selber (IPv6) existiert, für das Tutorial werde ich "tut.dyn.ip" annehmen
      Fritz!Box-Besitzer - insbesondere solche mit DS-lite-Anschluß - nutzen hierfür am besten den MyFritz!-Dienst
    • der Port 22 auf die Box weitergeleitet wurde (IPv4-"Portweiterleitung") bzw. in der Firewall des Routers freigegeben wurde (IPv6/DS-lite)



    Teil 1 - Server (E2-Box)

    Grundinstallation

    1. Paketinstallation
      Auf der Box benötigen wir lediglich ein oder zwei neue Pakete, und zwar

      • Auf sh4-Boxen das Paket enigma2-plugin-network-dropbear
        Installieren auf der Shell mit
        Code:
        opkg update
        opkg upgrade
        opkg install enigma2-plugin-network-dropbear
        Ausgabe während der Installation:
        Spoiler: 
        Code:
        Topf:~# opkg install enigma2-plugin-network-dropbear
        Installing enigma2-plugin-network-dropbear (0.55-3) to root...
        Downloading http://ipkserver.hdmedia-universe.com/sh4new/enigma2-plugin-network-dropbear_0.55-3_sh4.ipk.
        installing dropbear...
        Configuring enigma2-plugin-network-dropbear.
        successfully installed
        syncing disk
        Will output 1024 bit dss secret key to '/etc/dropbear/dropbear_dss_host_key'
        Generating key, this may take a while...
        Public key portion is:
        ssh-dss
        ...
        Fingerprint: md5 ...
        Will output 1024 bit rsa secret key to '/etc/dropbear/dropbear_rsa_host_key'
        Generating key, this may take a while...
        Public key portion is:
        ssh-rsa
        ...
        Fingerprint: md5 ...
      • Auf MIPS-Boxen dropbear + openssh-sftp-server
        Installation durch Eingabe folgender Kommandos:
        Code:
        opkg update
        opkg upgrade
        opkg install dropbear openssh-sftp-server
    2. Austausch des RSA Host Keys
      Durch folgende Kommandos tauschen wir nun noch den 1024 Bit RSA Host Key gegen einen mit 2048 Bit aus:
      Code:
      rm /etc/dropbear/dropbear_rsa_host_key
      dropbearkey -t rsa -s 2048 -f /etc/dropbear/dropbear_rsa_host_key
      Die Erzeugung eines so großen Schlüssels kann, insbesondere auf sh4, etwas dauern.


    Damit ist die Grundinstallation beendet und wir können uns nun statt per telnet auch per ssh mit der Box verbinden.


    Absicherung

    Damit uns später niemand beim Eingeben des Passworts über die Schulter gucken kann, wollen wir schlichtweg keines nutzen.
    Das geht ganz einfach, indem wir eine Autorisierung über "asymetrische Verschlüsselung" nutzen, also über ein Schlüsselpaar aus einem privatem und einem öffentlichen Schlüssel.

    1. Schlüsselerzeugung
      Ein solches Schlüsselpaar erzeugen wir unter Windows am einfachsten mit puttygen aus dem putty-Paket:

      Einfach die Voreinstellungen "SSH2-RSA" und "2048 Bits" belassen und auf [Generate] klicken. Danach möchte puttygen, daß man mit der Maus über den leeren Fensterbereich fährt, um wirklich zufällige Werte zu generieren.
    2. Erzeugtes Schlüsselpaar speichern
      Dem Schlüssel geben wir nun noch einen Namen (Feld "Key Comment"), sinnvoller Weise ist das "root@<client>" also z.B. "root@Smartphone" (Warum erkläre ich später).

      Auf Wunsch kann auch ein Passwort ("Key passphrase" und "Confirm passphrase") festgelegt werden, das immer dann eingegeben werden muß, wenn der Schlüssel benutzt werden soll. Soll der Zugang später mobil genutzt werden, z.B. auf dem Smartphone, ist das durchaus sinnvoll, damit der Key nicht unmittelbar mißbraucht werden kann, sollte er in fremde Hände gelangen.

      Nun können sowohl der "public key" als auch der "private key" durch Klick auf die entsprechenden Schaltflächen und Eingabe eines Dateinamens gespeichert werden. Durch Auswahl des Menüpunktes "Conversions -> Export OpenSSH key" kann der private Schlüssel zusätzlich noch im Format von OpenSSH gespeichert werden. Dies bitte auch tun.

      Für den Rest des Tutorials gehe ich davon aus, daß die Keys unter folgenden Namen gespeichert wurden:
      Public key: Tut.pub
      Private key: Tut.ppk
      OpenSSH key: Tut.ssh
    3. Die Box mit dem öffentlichen Schlüssel bekanntmachen
      Damit wir uns mit diesem Schlüsselpaar an der Box anmelden können, muß die Box den öffentlichen (public) Teil des Schlüssels kennen.
      Durch Markieren des gesamten öffentlichen Schlüssels im puttygen-Fenster plus "Rechtsklick -> Kopieren" bekommen wir diesen in die Zwischenablage.

      Diesen müssen wir nun auf der Box in eine Textdatei namens ~/.ssh/authorized_keys speichern.

      Für die, die diese Datei auf dem PC erzeugen und auf die Box kopieren wollen:
      Das ~ steht dabei je nach Image für /home/root oder /root (Einheitlichkeit war noch nie die Stärke von *ixen).
      Beim Erzeugen von Konfigurationsdateien für *ix-Systeme ist aber immer der abweichende Zeilenvorschub (Normal: CR+LF, also "Wagenrücklauf" + "Zeilenvorschub", *ix: Nur LF/Zeilenvorschub, *ixer schreiben also auf endlos breitem Papier ) zu beachten, dies ist ggf. vor dem Speichern der Datei im Texteditor umzustellen.

      Man kriegt den Key aber auch direkt per Telnet/ssh durch folgende Befehle gespeichert:
      Code:
      mkdir -p ~/.ssh
      cat >> ~/.ssh/authorized_keys
      nach dem zweiten Befehl kehrt die Box nicht wieder zum Prompt "root@box" zurück, sondern wartet auf weitere Eingaben.
      Dort nun unmittelbar den Key einfügen (Rechtsklick -> Einfügen oder auf der Tastatur Umschalttaste+Einfügetaste), einmal die Eingabetaste betätigen und dann "Strg+C" drücken.
      Dabei darf man aber nicht versehentlich auf anderen Tasten rumgrabbeln, sonst werden diese mit eingefügt ...

      Nun müssen noch die Dateirechte der authorized_key und des Verzeichnisses korrigiert werden, da sich dropbear sonst weigert, diese zu nutzen.
      Dazu eingeben:
      Code:
      chmod 700 ~/.ssh
      chmod 600 ~/.ssh/*


    Der ssh-Server ist nun soweit fertig für den Login mittels key eingerichtet.
    Geändert von SpaceRat (29.04.2014 um 07:05 Uhr)

  4. The Following 6 Users Say Thank You to SpaceRat For This Useful Post:



  5. #3
    VIP Avatar von SpaceRat
    Registriert seit
    12.08.2012
    Ort
    Midgard
    Beiträge
    416
    Thanks
    49
    Thanked 165 Times in 97 Posts
    Variante 1: Secure Shell/ssh mit (mehreren) Tunnel

    Teil 2a - Client (Windows; putty)

    Für den Zugriff per putty von einem Windows-Client aus ist es empfehlenswert, sich ein Profil anzulegen und abzuspeichern, um später jederzeit mit einem Klick eine Verbindung herstellen zu können.

    Verbindung herstellen

    1. Putty starten
    2. Profil-Grundeinstellungen
      In der Start-Ansicht von putty ...

      sind nur wenige Einstellungen vorzunehmen:
      1. Der Hostname (z.B. die MyFritz-Adresse) der Box, hier tut.dyn.ip
      2. Der Name des Profils, hier einfach "Tut"
      SSH und Port 22 sollten bereits eingestellt sein.
      Das Profil kann auf Wunsch jetzt bereits zwischengespeichert werden.
    3. Autorisierung auf "Private Key" umstellen
      Auf der linken Seite wechseln wir in die Ansicht "Connection -> SSH -> Auth" und nehmen folgende Einstellungen vor:

      1. Deaktivieren der "keyboard interactive"-Anmeldung
      2. Auswählen unseres in Teil 1 erzeugten "private keys"
    4. Einstellen des Benutzernamens
      Den Benutzernamen stellen wir in der Ansicht "Connection -> Data" ein:

      Hier ist einfach nur "root" einzutragen.
    5. Profil abspeichern
      Die Ansicht zurückwechseln auf "Session", dort die bereits vorab gespeicherte Sitzung "Tut" aus der Liste auswählen und auf [Save] klicken.
    6. Verbindung testen
      Mit Klick auf "Open" sollte sich ohne weiteres Zutun (Beim ersten Mal muß noch der Fingerabdruck des Servers auf der Box bestätigt werden) eine Terminal-Sitzung zu unserer Box öffnen:

      Auf diesem Bild habe ich etwas hochgescrollt, um zu überprüfen, daß der Login tatsächlich per public key erfolgt ist.

      Durch Eingabe von "exit" beendet sich die Sitzung und auch putty ...


    Es ist nach derzeitigem Wissensstand absolut sicher, eine solche Verbindung nach außen freizugeben.
    Um sicherzustellen, daß sich niemand mehr über Login/Passwort einloggen kann, kann (sollte) nach erfolgreichem Test die folgende Zeile in der Datei /etc/inetd.conf:
    Code:
    ssh  stream tcp6 nowait root /usr/sbin/dropbear dropbear -i
    wie folgt abgewandelt werden:
    Code:
    ssh  stream tcp6 nowait root /usr/sbin/dropbear dropbear -i -s
    Mit dieser Einstellung ist dann ein Login über Kennwort per ssh überhaupt nicht mehr möglich (Wohl aber noch per Telnet, Webinterface, etc. pp.).

    Shell-Zugriff auf die Box von außerhalb haben wir nun also ... aber das ist vermutlich für die meisten Benutzer unterwegs der uninteressanteste Aspekt.

    Wir haben aber in einem Rutsch auch gleich einen sftp-Server geschaffen, der sich - zumindest mit einem richtigen FTP-Client - auch genauso nutzen läßt wie ein normaler FTP-Server, nur eben sicher.
    Wie man z.B. den FileZilla-Client für den Zugriff auf diesen Server nutzt, wird hier erklärt.
    Auch hier ist - nach Anpassung der inetd.conf - keine Anmeldung über Benutzername und Kennwort mehr möglich, sondern nur für den Besitzer des privaten Schlüssels.

    Wie aber kommen wir nun auch sicher an das Web-Interface oder den Stream-Server?

    ssh-Tunnel einrichten

    1. putty erneut starten
    2. Profil laden
      Wir laden das vorher erstellte Profil durch Auswählen in der Liste und Klick auf "Load".
    3. Tunnel erstellen
      Wechseln in die Ansicht "Connection -> SSH -> Tunnels"
      und dort die gewünschten Einstellungen vornehmen:

      Es können beliebig viele Tunnel definiert werden, wobei jeweils einzustellen ist:
      1. Source Port = Der Port auf der lokalen Maschine (Dem Client)
      2. Destination = IP/Name plus Port auf der Zielmaschine (Der E2-Box)
      Im abgebildeten Beispiel wird der lokale Port 17080 auf den Port 80 auf der E2-Box selber umgeleitet.
      Diese beiden Angaben jeweils ausfüllen und auf [Add] klicken, danach ggf. für weitere Ports wiederholen.
    4. Profil wieder abspeichern
      Nachdem alle gewünschten Tunnel definiert wurden, einfach wieder auf die Ansicht "Sessions" zurückwechseln und das Profil durch Klick auf "Save" neu abspeichern.
    5. Tunnel starten
      Sobald nun mit diesem Profil wieder eine Verbindung hergestellt wird (Profil auswählen -> Load -> Open), werden gleichzeitig die eingestellten ssh-Tunnel geöffnet.

      Das bedeutet:
      Solange die ssh-Sitzung läuft, sind die eingestellten Zieladressen/Ports unter der Adresse des Clients plus dem eingestellten Port ansprechbar.
      Um also den Web-Server der E2-Box aufzurufen (Siehe Beispiel oben), wird einfach im Webbrowser des Clients die Adresse http://127.0.0.1:17080 aufgerufen. Dieser Aufruf wird dann von putty durch den ssh-Tunnel zur Box transportiert und auf dieser an "localhost:80" weitergereicht ... also den Webserver der Box.


    Komfort:

    Wenn alles zur Zufriedenheit eingerichtet hat, kann man sich ganz einfach eine Desktop-/Schnellstart-/Sonstwas-Verknüpfung
    mit dem Ziel
    d:\path\to\putty.exe -load "my session"
    also z.B.
    C:\Programme\putty\putty.exe -load "Tut"
    anlegen.

    Danach genügt ein Doppelklick auf diese Verknüpfung und putty startet, baut eine ssh-Verbindung auf und stellt alle eingestellten Tunnel her.
    Geändert von SpaceRat (29.04.2014 um 10:30 Uhr)

  6. The Following 6 Users Say Thank You to SpaceRat For This Useful Post:



  7. #4
    VIP Avatar von SpaceRat
    Registriert seit
    12.08.2012
    Ort
    Midgard
    Beiträge
    416
    Thanks
    49
    Thanked 165 Times in 97 Posts
    Variante 1: Secure Shell/ssh mit (mehreren) Tunnel

    Teil 2b - Client (Smartphone/Phablet/Tablet; ConnectBot)

    Für den Zugriff vom Smartphone aus benötigen wir einen ssh-Client mit Tunnelunterstützung.
    Empfehlenswert ist z.B. ConnectBot.

    Die eigentlich Einrichtung ist weitgehend selbsterklärend.

    1. Schlüssel auf's Smartphone kopieren
      Den in Teil 1 unter Schlüsselerzeugung - Schritt 2 gespeicherten Schlüssel im OpenSSH-Format, hier also Tut.ssh ins Hauptverzeichnis des internen Speichers vom Smartphone kopieren.
    2. ConnectBot starten
    3. Verbindung erzeugen

      Dazu einfach unten im Adressfeld
      Code:
      root@<Dyn-Hostname der Box>
      eintragen, also z.B.
      Code:
      root@tut.dyn.ip
    4. Privaten Schlüssel importieren
      In ConnectBot über
      Menütaste -> "Pubkeys verwalten" -> Menütaste -> "Importieren"
      zum Import der Keys wechseln und die Datei "Tut.ssh" auswählen.
    5. Privaten Schlüssel aktivieren

      Den importierten Schlüssel antippen, so daß das Vorhängeschloß grün angezeigt wird.
    6. Tunnel anlegen
      Zurück in der Hostliste von ConnectBot lange auf unseren Host "tut.dyn.ip" tippen und "Port-Weiterleitungen editieren ..." auswählen.

      1. Über Menütaste -> "Port-Weiterleitung hinzufügen" kann ein neuer Tunnel angelegt werden.
      2. Langes Tippen auf eine vorhandene Port-Weiterleitung und man kann diese ändern oder löschen.

      Der Aufbau der Tunnel ist fast identisch wie bei putty:

      Einziger Unterschied ist, daß jede einzelne Port-Weiterleitung auch einen eindeutigen Spitznamen erhält, z.B. "Web"

      Sobald alle Tunnel angelegt sind, kann die Verbindung hergestellt werden ...
    7. ssh-Verbindung samt Tunnel herstellen
      Zurück in der Hostliste kann eine Verbindung durch einfaches Antippen aufgebaut werden.
      Zum Trennen einer Verbindung "exit" eingeben oder Menütaste -> "Verbindung trennen" auswählen.
    8. Zugriff auf die Ressourcen der Box
      Solange ConnectBot die ssh-Verbindung zur Box aufrecht erhält, sind auch die für diesen Host definierten Tunnel ("Port-Weiterleitungen") aktiv und können vom Smartphone benutzt werden.
      Man könnte nun z.B. in DreamDroid ein Profil erzeugen, welches 127.0.0.1 Port 17080 als Adresse des Web-Servers nutzt.


    Ebenso wie die Verbindung über putty ist auch diese Verbindung nach dem derzeitigen Stand der Technik weder abzuhören noch ist es möglich, unerlaubt Zugriff zu erlangen ohne den privaten Schlüssel zu besitzen.
    (Es sei denn, Google ist so nett, den Inhalt Eures Smartphones mit der NSA zu synchronisieren, aber das ist eine andere Geschichte ....)
    Geändert von SpaceRat (29.04.2014 um 10:28 Uhr)

  8. The Following 4 Users Say Thank You to SpaceRat For This Useful Post:



  9. #5
    VIP Avatar von SpaceRat
    Registriert seit
    12.08.2012
    Ort
    Midgard
    Beiträge
    416
    Thanks
    49
    Thanked 165 Times in 97 Posts
    Variante 1: Secure Shell/ssh mit (mehreren) Tunnel

    Teil 3 - weitergehende Informationen

    Tips zu den Tunnels

    • Das Ziel kann nicht nur die E2-Box selber sein ...
      ... sondern jede beliebige Adresse, welche die Box erreichen kann.

      Blödes Beispiel:
      Würde man den Tunnel "L1337 www.google.com:80" einrichten, dann könnte man auf dem Client unter der Adresse http://127.0.0.1:1337 die Zieladresse www.google.com erreichen.

      Ein sinnvollerer Anwendungszweck wäre es, über nur eine ssh-Verbindung zu einer E2-Box auch ggf. vorhandene Zweit- und Drittboxen mit anzusprechen, statt für diese separate SSH-Verbindungen einzurichten.
      D.h. eine einzige Box mit ssh genügt für den Zugriff auf das gesamte Heimnetz!
      Umgekehrt braucht Ihr für diese Zugriffsart auch gar keinen ssh-Server auf der Box, wenn es im Heimnetz bereits einen entsprechend sicher eingerichteten ssh-Server gibt (z.B. auf einem durchlaufenden PC, einem NAS oder dem Router ...). Die Tunnel lassen sich dann genauso gut auch mit dem vorhandenen ssh-Server einrichten.
    • Auf der Zielbox verhält sich die "normale" IP der Box u.U. anders als "localhost":
      Ist auf der E2-Box die Autorisierung fürs Streaming inaktiv und der Tunnel wird als
      "L17080 localhost:80"
      eingerichtet, erfolgt auch beim Zugriff auf's Web-Interface keine Passwort-Abfrage mehr!
      Hat die E2-Box aber z.B. die IP 192.168.1.17 und man stellt den Tunnel auch so ein ...
      "L17080 192.168.1.17:80"
      dann wird man nach dem Passwort gefragt (Wenn die Autorisierung im Webif nicht komplett abgeschaltet ist).


    "Serviervorschlag"

    Ich empfehle, für den "lokalen Port" die letzte Zahl der lokalen IP und den Standardport zu nutzen, für einen Webserver (Standardport 80) auf einer Box, die im LAN die IP 192.168.1.17 hat wäre das dann z.B. Port 17080, für den https-Server 17443, für FTP die 17021 usw.
    Achtung: Der höchstmögliche Port ist 65535 und der niedrigstmögliche je nach System die 1025. Für den Streaming-Port böte sich somit 17801 an, da 178001 zu hoch wäre.

    Mit den vier Tunneln
    L17021 localhost:21
    L17023 localhost:23
    L17080 localhost:80
    L17801 localhost:8001
    hätte man alle Ports per ssh getunnelt, die man für Tools wie Bouquet Editor Suite, DreamSet etc. pp. braucht, nämlich Telnet (Port 23), ftp (Port 21) und Web (Port 80) sowie zusätzlich noch Streaming (Port 8001).

    Schaltet man nun noch die Autorisierung für Streaming aus, dann muß man außer für telnet und ftp (Welches man unterwegs vermutlich eh nicht braucht) auch nie mehr ein Passwort einzugeben (Ich betrachte es als selbstverständlich, daß diese Dienste nicht anderweitig freigegeben werden ...), denn die E2-Web-Interfaces betrachten Zugriffe von localhost auf localhost immer als Streaming, auch wenn dabei das Web-Interface aufgerufen wird.

    Die (dadurch entfallende) Passwortabfrage trägt in diesem Szenario auch kein Stück weit zur Sicherheit bei, da bereits eine höherwertige Sicherheit durch ssh erzielt wird, die Gefahr, daß das Passwort beim Eingeben ausgespäht würde wiegt deshalb höher.

    Tip zu ssh als Firewall-Durchbrecher:
    Viele Firewalls sind auch mit DPI (Deep Packet Inspection) nicht in der Lage, ssh-Traffic von https-Traffic zu unterscheiden. Wenn man sich also häufiger in derart per Firewall verrammelten Netzen aufhält, aus denen heraus man nur http und https öffnen darf, kann man diese u.U. durch seinen ssh-Tunnel austricksen, sofern man ssh/dropbear auf Port 443 (https) statt Port 22 (ssh) lauschen läßt ... *Zwinker*

    Tip zu den Schlüsselpaaren:
    Es ist weitgehend sinnfrei, für mehrere im Heimnetz befindliche Boxen auch mehrere Schlüsselpaare anzulegen. Gelingt es allen Schutzmaßnahmen zum Trotz doch jemandem ein Gerät im Heimnetz zu hacken, so geht die Wahrscheinlichkeit gegen Null, daß er nicht zumindest auch alle anderen E2-Boxen "besuchen" kann.
    Spart Euch also die Arbeit und verwendet dieselbe authorized_keys ruhig auf allen Boxen ...

    Was hingegen Sinn macht, ist die Erstellung von weiteren Schlüsselpaaren je Client. Kommt nämlich ein Client bzw. ein Speichermedium mit dem privaten Schlüssel (z.B. ein USB-Stick) abhanden oder wird ein Key kompromittiert (z.B. weil Euch nach dem Verkauf einer alten Festplatte siedendheiß einfällt, daß Ihr die Platte gar nicht überschrieben habt ...), so kann der Zugriff für diesen Client/Key gesperrt werden, indem der zugehörige öffentliche Schlüssel aus allen authorized_keys entfernt wird. Aus genau diesem Grund solltet Ihr auch als Kommentar für den Schlüssel "root@Client" verwenden, um bei mehreren Keys in authorized_keys den richtigen (zu löschenden) lokalisieren zu können.
    Bei Verwendung des selben Keys für alle Clients müßtet Ihr danach alle Clients neu mit Keys bestücken ...
    Geändert von SpaceRat (29.04.2014 um 11:08 Uhr)

  10. The Following 6 Users Say Thank You to SpaceRat For This Useful Post:



Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •