Announcement: there is an English version of this forum on Mahlzeit, kann man einen Debian-PC ohne (bzw. mit unbekannter) IP-Adresse irgendwie erreichen? Mit so einem Mittelding zwischen Wake-on-Lan (der PC läuft schon) und netcat (dafür fehlt die Adresse)? Die MAC weiß ich eigentlich auch nicht, aber das ließe sich ändern. Es würde reichen, wenn der ein einziges eindeutiges Paket empfängt. Daraufhin würde er das Netzwerk normal konfigurieren und den sshd starten. Es ist kein Notfall, ich installiere so einen PC gerade neu. Der soll auch in einem fremden, völlig unbekannten Netzwerk laufen, wo die Netzwerkkonfiguration evt. von Hand gemacht wird oder auch nicht. Deshalb möchte ich DHCP vermeiden, auch wenn damit alles ganz einfach funktionieren würde.
Bauform B. schrieb: > Mahlzeit, > > kann man einen Debian-PC ohne (bzw. mit unbekannter) IP-Adresse > irgendwie erreichen? Mit so einem Mittelding zwischen Wake-on-Lan (der > PC läuft schon) und netcat (dafür fehlt die Adresse)? Die MAC weiß ich > eigentlich auch nicht, aber das ließe sich ändern. Es würde reichen, > wenn der ein einziges eindeutiges Paket empfängt. Daraufhin würde er das > Netzwerk normal konfigurieren und den sshd starten. Die MAC Adresse reicht aus. Über ARP wird die MAC Adresse aus der IP Adresse ermittelt. Hat man die MAC spart man sich diesen Schritt sogar. > Es ist kein Notfall, ich installiere so einen PC gerade neu. Der soll > auch in einem fremden, völlig unbekannten Netzwerk laufen, wo die > Netzwerkkonfiguration evt. von Hand gemacht wird oder auch nicht. > Deshalb möchte ich DHCP vermeiden, auch wenn damit alles ganz einfach > funktionieren würde. Der Kontext ist unklar. Was hat das eine mit dem anderen zu tun? Was hält dich davon ab die IP Konfiguration vorzunehmen damit du JETZT auf den PC zugreifen kannst? Was hat eine spätere anderen Konfiguration damit zu tun? Kostet dich jede IP Konfig extra oder wie sieht das aus? Deine Frage zeigt auch eindeutige kritische Lücken in deinem Wissen über Netzwerktechnik. Evt. willst du diese schließen bevor du großmächtig irgendwelche PCs für irgendwelche Umgebungen installierst?
:
Bearbeitet durch User
Cyblord -. schrieb: > Was hält dich davon ab die IP Konfiguration vorzunehmen damit du JETZT auf > den PC zugreifen kannst? Nichts, jetzt ist er noch griffbereit. > Was hat eine spätere anderen Konfiguration damit zu tun? > Kostet dich jede IP Konfig extra oder wie sieht das aus? Später steht er in einer Halle und ich müsste 12km fahren. In dem Zustand ist das Netzwerk zunächst nicht konfiguriert, anschließend spielt der Benutzer seine Konfiguration ein (oder nicht).
Unter Windows z.B.: arp -s 157.55.85.212 00-aa-00-62-c6-09 ... Fügt statischen Eintrag hinzu. unter Linux sicher ähnlich. Im Lokalen Netz (ohne Router) läuft die Kommunikation nur über die MAC Adresse. Die Verbindung zwischen IP und MAC passiert über das ARP Adress Resolution Protokoll. ifconfig zeigt auch die MAC Adresse an ohne das eine IP existiert.
:
Bearbeitet durch User
Bauform B. schrieb: > Später steht er in einer Halle und ich müsste 12km fahren. Das klingt nach einer Verbindung über das Internet. Damit nützt Dir die MAC genau garnichts, die wird nur im lokalen Netz benutzt und vom Router ersetzt.
Bauform B. schrieb: > Später steht er in einer Halle und ich müsste 12km fahren. In dem > Zustand ist das Netzwerk zunächst nicht konfiguriert, anschließend > spielt der Benutzer seine Konfiguration ein (oder nicht). Ja nur dann hängt doch sowieso alles vom Nutzer und dessen Konfig ab. Was willst du dann da vorbereitend machen? Das ganze hört sich wirklich wirr an. Wenn ein späterer Nutzer das alles konfiguriert dann klärt man mit diesem einen möglichen Fernzugriff.
Bauform B. schrieb: > Mit so einem Mittelding zwischen Wake-on-Lan (der PC läuft schon) und > netcat (dafür fehlt die Adresse)? Hostname / DNS
Bauform B. schrieb: > Es würde reichen, > wenn der ein einziges eindeutiges Paket empfängt. Daraufhin würde er das > Netzwerk normal konfigurieren und den sshd starten. Im Prinzip geht das auf Basis der MAC-Adresse ohne jedwedes IP. Du müsstest einen Service schreiben, der mittels Raw Socket auf einen LAN Frame mit einem eigenen Ethertype horcht (wie 0x0800 IP und 0x0806 ARP) und daraufhin das Netz konfiguriert. Dein Problem dürfte jedoch darin bestehen, dass dieses Verfahren nicht routet. Der Sender muss sich im gleichen Layer 2 Netz befinden. Über handelsübliche Router-Ketten vom Internet geht das nicht.
:
Bearbeitet durch User
Bauform B. schrieb: > Später steht er in einer Halle und ich müsste 12km fahren. In dem > Zustand ist das Netzwerk zunächst nicht konfiguriert, anschließend > spielt der Benutzer seine Konfiguration ein (oder nicht). Der Benutzer konfiguriert und betreibt SEIN lokales Netz, und du möchtest versuchen, hinter seinem Rücken und ohne Beachtung seiner Routing-, Firewall- und sonstigen Regeln auf einen der Rechner im Netz zugreifen?
Cyblord -. schrieb: > Ja nur dann hängt doch sowieso alles vom Nutzer und dessen Konfig ab. > Was willst du dann da vorbereitend machen? Wünschen würde ich mit einen Daemon, der an eth0 lauscht, egal, wie das konfiguriert ist. Wenn der ein "magisches Paket" empfängt, konfiguriert er eth0:1. Auf dem Kabel gibt es (auch) ein Subnetz für mich, damit ist auch das kein Problem: Oliver R. schrieb: > Das klingt nach einer Verbindung über das Internet. Damit nützt Dir die > MAC genau garnichts
Rolf schrieb: > hinter seinem Rücken und ohne Beachtung seiner > Routing-, Firewall- und sonstigen Regeln auf einen der Rechner im Netz > zugreifen? Ist nicht so ungewöhnlich, wenn der Betreiber des Zielnetzes mit einer Fernwartung explizit einverstanden ist und ggf per Firewall kontrolliert. Je nach Grad der Sicherheitsphilosophie will er aber vielleicht keinen Zugriff auf das ganze Netz zulassen. In diesem Fall findet man bei Geräten unter Fremdwartung mitunter zwei Interfaces. Eines im Produktionsnetz und eines im Wartungsnetz oder direkt an einem Service-Router.
Rolf schrieb: > Der Benutzer konfiguriert und betreibt SEIN lokales Netz, und du > möchtest versuchen, hinter seinem Rücken und ohne Beachtung seiner > Routing-, Firewall- und sonstigen Regeln auf einen der Rechner im Netz > zugreifen? Richtig -- nur nicht "hinter seinem Rücken", geheim oder zwielichtig ist da garnichts.
Bauform B. schrieb: > Cyblord -. schrieb: >> Ja nur dann hängt doch sowieso alles vom Nutzer und dessen Konfig ab. >> Was willst du dann da vorbereitend machen? > > Wünschen würde ich mit einen Daemon, der an eth0 lauscht, egal, wie das > konfiguriert ist. Wenn der ein "magisches Paket" empfängt, konfiguriert > er eth0:1. Und wie bekommst du überhaupt Zugriff auf den Rechner? Hat der eine öffentliche statische IP, gibt es NAT oder VPN? > Auf dem Kabel gibt es (auch) ein Subnetz für mich Was bedeutet das? Der Satz ergibt keinen Sinn. Subnetze gibt es bei IP und haben mit Kabeln nichts zu tun. Und mit Layer 2 auch nicht. (prx) A. K. schrieb: > Ist nicht so ungewöhnlich, wenn der Betreiber des Zielnetzes mit einer > Fernwartung explizit einverstanden ist Hier soll aber keine normale Fernwartung betrieben werden, sondern auf ein magisches Paket hin soll sich ein Netzwerkinterface um konfigurieren. Warum auch immer. Mich würde interessieren warum eine normale Fernwartungslösung nicht in Frage kommt.
:
Bearbeitet durch User
Bauform B. schrieb: > kann man einen Debian-PC ohne (bzw. mit unbekannter) IP-Adresse > irgendwie erreichen? Mit so einem Mittelding zwischen Wake-on-Lan (der > PC läuft schon) und netcat (dafür fehlt die Adresse)? Die MAC weiß ich > eigentlich auch nicht, aber das ließe sich ändern. Du brauchst nur dafür zu sorgen, dass auf dem fraglichen PC irgendein Dienst läuft, der Broadcasts empfängt und Unicast antwortet. Kinderkram.
Alle Verfahren ohne bereits vorher eingerichtetem IP leiden unter dem gleichen Problem: Routing geht eigentlich nicht. Es muss dort im Layer 2 Netz eine bekannte Komponente geben, die mitspielt. Ist eine Art Henne-und-Ei Frage. Das Routing freilich kann man überlisten, da keine bidirektionale Kommunikation erforderlich ist. Man sendet einen UDP-Frame mit gewünschter Ziel-IP und der bekannten MAC-Adresse. Wenn die Firewall das per NAT oder über eine VPN explizit zulässt, landet der beim Zielsystem.
Ob S. schrieb: > Du brauchst nur dafür zu sorgen, dass auf dem fraglichen PC irgendein > Dienst läuft, der Broadcasts empfängt und Unicast antwortet. Broadcasts werden üblicherweise nicht geroutet.
(prx) A. K. schrieb: > Das Routing freilich kann man überlisten ... muss dann aber im Zielsystem schon irgendein rudimentäres IP passend zum IP-Netz drauf haben, damit der überhaupt darauf horcht. Das Henne-und-Ei Problem. Routen muss das freilich nicht können.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Ob S. schrieb: >> Du brauchst nur dafür zu sorgen, dass auf dem fraglichen PC irgendein >> Dienst läuft, der Broadcasts empfängt und Unicast antwortet. > > Broadcasts werden üblicherweise nicht geroutet. Das ist wohl wahr. Aber der TO hatte ja bereits WOL in's Spiel gebracht. Scheint also die Möglichkeit zu haben, im Ziel-LAN WOL-Pakete zu erzeugen. Die Frage ist eigentlich dann nur noch: kann er den WOL-Paketen auch noch eigenen Extra-Payload verpassen?
Ob S. schrieb: > Das ist wohl wahr. Aber der TO hatte ja bereits WOL in's Spiel gebracht. > Scheint also die Möglichkeit zu haben, im Ziel-LAN WOL-Pakete zu > erzeugen. Die Frage ist eigentlich dann nur noch: kann er den > WOL-Paketen auch noch eigenen Extra-Payload verpassen? Wozu? Wenn er Pakete ins lokale LAN senden kann, kann er schlicht beliebige Pakete senden. Ein Dienst läuft auf dem PC und schaut welche Interfaces laufen und hängt sich ran und lauscht auf ein spezielles Paket. Das geht schon. Ist aber Unsinn. Wenn es mit dem Wissen des Betreibers passiert, könnte man einfach ein Script schreiben welches der Betreiber nach seiner Konfig startet und welches ein Interface für die Fernwartung konfiguriert. Was aber auch fragwürdig wäre, denn warum wird der PC nicht einmal korrekt, mit allen erforderlichen Interfaces konfiguriert? Wozu das Ganze? Hier soll es aber wohl unter dem Radar ablaufen.
:
Bearbeitet durch User
Cyblord -. schrieb: > Hier soll aber keine normale Fernwartung betrieben werden ... sondern eine un-normale und Kosten sparende Fernwartung. So liest sich das jedenfalls. Ich bin schon Backboxes begegnet, die über ARP über einem Service-PC im LAN konfiguriert wurden, weil keine Konsole und nix. Auf dem Service-PC Zieladresse und bekannte MAC in die ARP Liste eintragen, und dann PING. Die Kiste nahm einfach jede IP-Adresse, die bei ihr mit der richtigen MAC eintrudelte, als ihre an. Aus dem Netz heraus kam man dann vom Service-PC heraus ran. Nur ändert das nichts daran, dass man für solche Verfahren in ebendiesem Layer 2 Netz sein muss.
:
Bearbeitet durch User
(prx) A. K. schrieb: > ... sondern eine un-normale und Kosten sparende Fernwartung. So liest > sich das jedenfalls. Welche zusätzlichen Kosten fallen denn an, wenn man ein zusätzliches Interface für die Fernwartung direkt konfiguriert anstatt es später über magische Pakete zu tun? > Nur ändert das nichts daran, dass man für solche > Verfahren in ebendiesem Layer 2 Netz sein muss. Was "Fernwartung" dann wieder ad absurdum führt. Dann ist es einfach ein (weiterer) Zugriff über was auch immer (ssh z.B.) und nichts anderes.
:
Bearbeitet durch User
Cyblord -. schrieb: > könnte man einfach ein Script schreiben welches der Betreiber > nach seiner Konfig startet und welches ein Interface für die Fernwartung > konfiguriert. Was aber eine irgendwie geartete Konsole voraussetzt. Bei IoT-Devices hat man die oft nicht, was zu einiger Phantasie bei der Erstkonfiguration führt.
(prx) A. K. schrieb: > Bei IoT-Devices Bauform B. schrieb: > kann man einen Debian-PC Jaja Und auch für IOT Devices gibt es bekannte Lösungen für die Einrichtung. DHCP wäre eine gute Lösung z.B. Oder eine default IP (vgl. Shellys). Darum gehts hier aber nicht.
:
Bearbeitet durch User
Cyblord -. schrieb: > Wozu? Wenn er Pakete ins lokale LAN senden kann, kann er schlicht > beliebige Pakete senden. Nein. Es kann ja durchaus sein, dass er dazu wiederum einen Dienst benutzt, der nicht unter seiner Kontrolle steht. Einfaches Beispiel: Fritzbox. Man kann darüber (mit den entsprechenden Rechten) WOL-Pakete in's LAN senden. Was man aber nicht kann: denen eigenen Payload zu verpassen. Und auch der Absender der WOL-Pakete ist zwingend die FB-LAN-Adresse. Damit geht's also z.B. nicht. Und das dürfte bei zumindest vielen "Internet-Routern" (sofern sie überhaupt das WOL-Feature haben) ganz genauso sein. Schon aus Sicherheitsgründen.
Ob S. schrieb: > Nein. Es kann ja durchaus sein, dass er dazu wiederum einen Dienst > benutzt, der nicht unter seiner Kontrolle steht. Dann kann er auch kein eth Interface konfigurieren. Ganz einfach. Abgesehen davon hat er zum Thema NAT usw. noch nichts geschrieben. Daher muss man davon ausgehen er hat vollen Zugriff aufs LAN. Wie auch immer.
:
Bearbeitet durch User
Wenn du da dein eigenes Subnetz hast, liegt das vermutlich in einem VLAN. Haenge also einfach einen DHCP-Server in dieses VLAN und informiere den Netzbetreiber darueber. Der muss dann naemlich das VLAN-Relaying fuer dieses Subnetz ausschalten. Wenn dein Geraet dann initial "ausgerollt" ist, kannst du bei deinem DHCP-Server nachsehen welche IP-Adresse dein Geraet hat. Ueber die kannst du es dann ganz normal erreichen und eine statische IP eintragen. In einem aehnlich gelagerten Fall, wurde einfach mit einem NMAP Pingscan nach neuen Adressen gesucht. Das waren dann die "Neuen". Die wurden dann statisch konfiguriert und fettich war... Den Pingscan koennte der Netzbetreiber dir aber uebelnehmen. :) Stellersichnichtsoan!
Cyblord -. schrieb: > Und wie bekommst du überhaupt Zugriff auf den Rechner? Hat der eine > öffentliche statische IP Der Rechner natürlich nicht, aber der Router, an dem er hängt. Dachte ich bis gerade eben :( Cyblord -. schrieb: > Daher muss man davon ausgehen er hat vollen Zugriff aufs LAN. Nein, hat er doch nur vielleicht. Damit und überhaupt wird mir das Ganze zu unübersichtlich. Die Lösung (prx) A. K. schrieb: > Cyblord -. schrieb: >> könnte man einfach ein Script schreiben welches der Betreiber >> nach seiner Konfig startet und welches ein Interface für die Fernwartung >> konfiguriert. > > Was aber eine irgendwie geartete Konsole voraussetzt. Bei IoT-Devices > hat man die oft nicht, was zu einiger Phantasie bei der > Erstkonfiguration führt. ist viel realistischer, auch, wenn's keine Tastatur gibt. Früher hat man DIL-Schalter oder Jumper benutzt ;) Auf jedem Fall vielen Dank für die Aufklärung!
Bauform B. schrieb: > Der Rechner natürlich nicht, aber der Router, an dem er hängt. Dachte > ich bis gerade eben :( Wenn Business-Anschluss, stehen die Chancen gut. Sonst kanns auf eine dynamische oder halbstatische IP rauslaufen, und das vielleicht nur über IPv6.
Cyblord -. schrieb: > Dann kann er auch kein eth Interface konfigurieren. Braucht er auch nicht. Wieder einfaches Beispiel, speziell für dich, da du anscheinend den Wink mit dem Zaunpfahl nicht kapierst: Also wieder: Fritzbox. Da hast du (selbst als "Admin") nicht das Recht, zu machen was du willst. Der "Admin" ist halt nicht root. Und das dürfte bei der überwältigenden Mehrheit der kommerziellen Internet-GWs nicht anders sein. Und nicht nur bezüglich der der so abschätzig beurteilen "Plastic-Consumer-Router". Da wird kein NIC-Interface konfiguriert. Sondern nur ein Dienst des GW benutzt, über den es möglich ist, WOL-Broadcasts in's LAN zu versenden. Ich kenne aus eigener Erfahrung z.B.: Unify (UDMPro)->same behaviour > Abgesehen davon hat er zum Thema NAT usw. noch nichts geschrieben. Daher > muss man davon ausgehen er hat vollen Zugriff aufs LAN. Eher nicht. Wenn er den hätte, wäre die ganze Frage ziemlich unsinnig. Allerdings: der TO ist BauformB. Würde also wiederum doch irgendwie passen...
Motopick schrieb: > ...NMAP Pingscan... > Den Pingscan koennte der Netzbetreiber dir aber uebelnehmen. :) Wie uebel wäre wohl ein Test auf 2 bis 3 bestimmte Adressen? So mit "arping -i eth0 -c1 -0 192.168.178.1". Das gibt doch nur je 1 bis 2 ganz harmlose alltägliche Pakete, oder? Damit wüsste ich immerhin, ob ich in einem bekannten Netz bin und könnte eine passende Config benutzen oder mich still verhalten.
Bei IPv6 hast du immer auch Link-Local Adressen (fe80::...), die aus der MAC-Adresse erzeugt werden. Hast Du die MAC, hast Du die zugehörige IP. Die ist zwar nur in der aktuellen Broadcast Domain erreichbar, aber das reicht ja oft auch. Damit musst Du nichts umkonfigurieren, das ist eh immer da. fchk
Frank K. schrieb: > Bei IPv6 hast du immer auch Link-Local Adressen (fe80::...) Man kann das auch ausschalten. Ist aber ein bisschen ein Krampf. Das ist von einem meiner Server:
1 | root@duck:~# ifconfig eth0 |
2 | eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 |
3 | inet 10.60.1.2 netmask 255.255.255.0 broadcast 10.60.1.255 |
4 | inet6 fc00:4::a3c:102 prefixlen 120 scopeid 0x0<global> |
5 | ether 00:ff:01:01:02:01 txqueuelen 1000 (Ethernet) |
6 | RX packets 807036 bytes 108349431 (103.3 MiB) |
7 | RX errors 0 dropped 0 overruns 0 frame 0 |
8 | TX packets 1015386 bytes 161836278 (154.3 MiB) |
9 | TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 |
10 | |
11 | root@duck:~# |
Man kann das zwar nicht immer machen. Ein Router geht z.B. nicht ohne das link-local zeug. Sollte man nur machen, wenn man weiss, was man tut, und sich sicher ist, das man es wirklich nicht braucht.
> Das gibt doch nur je 1 bis 2 ganz > harmlose alltägliche Pakete Ja die stoeren wohl keinen. > Damit wüsste ich immerhin, ob ich in > einem bekannten Netz bin und könnte eine passende Config benutzen oder > mich still verhalten. Nach einem zuverlaessigen guten Plan klingt das aber auch nicht. Wenn man Technik ausrollt, sollte das ganze schon etwas besser sein. Wenn man sich keinen Wolf laufen will... Einen zuverlaessigen Plan habe ich uebrigens oben skizziert.
Lass sich das Netzwerk-Interface über DHCP konfigurieren und greife über einen Reverse-Proxy-Dienst wie Ngrok z.B. auf ssh zu. Wenn das Netzwerk vor Ort nicht kooperiert, hast Du meist eh verloren. Dann hilft nur noch Zugriff über Mobilfunk oder evtl. offene Hotspots. https://www.endtoend.ai/tutorial/ngrok-ssh-forwarding/
Bauform B. schrieb: > kann man einen Debian-PC ohne (bzw. mit unbekannter) IP-Adresse > irgendwie erreichen? Mit so einem Mittelding zwischen Wake-on-Lan (der > PC läuft schon) und netcat (dafür fehlt die Adresse)? Die MAC weiß ich > eigentlich auch nicht, aber das ließe sich ändern. Es würde reichen, > wenn der ein einziges eindeutiges Paket empfängt. Daraufhin würde er das > Netzwerk normal konfigurieren und den sshd starten. > > Es ist kein Notfall, ich installiere so einen PC gerade neu. Der soll > auch in einem fremden, völlig unbekannten Netzwerk laufen, wo die > Netzwerkkonfiguration evt. von Hand gemacht wird oder auch nicht. > Deshalb möchte ich DHCP vermeiden, auch wenn damit alles ganz einfach > funktionieren würde. Auch nachdem ich den ganzen Thread gelesen habe, fällt es mir immer noch einigermaßen schwer zu verstehen, was das Ganze soll. Dein "eindeutiges Paket" muß ja irgendwo her kommen, Du würdest dazu erstens ein Programm brauchen, das das Paket versendet, und ein zweites Programm, welches es empfängt. Wenn Du nicht in dem betreffenden Netzwerk bist, dann ist das jedenfalls nicht ganz einfach. Was ich allerdings verstanden zu haben glaube, ist, daß es dabei um eine Art (womöglich temporären) Fernwartungszugang gehen soll. Ist das korrekt? Wenn ja, dann wäre mein Ansatz ein anderer -- entweder ein VPN oder sogar ein einfacher SSH-Tunnel, den Dein Fernzuwartender optional bei Bedarf starten und stoppen kann. Damit wäre netzwerkseitig nur ein kleiner Server im Internet nötig, den die Maschine erreichen kann, im Prinzip und mit ein paar Tricks würde da sogar ein Docker- oder LXC-Container ausreichen. Der Rest wäre relativ überschaubar: autossh(1) installieren, dazu ein systemd-Unitfile in (zB.) /etc/systemd/system/autossh_username.service (bitte unten meine Anmerkungen zu Ersetzungen beachten) ablegen, und zwar mit dem folgenden Inhalt:
1 | [Unit] |
2 | Description=Keeps a tunnel to 'example.com' open |
3 | After=network-online.target ssh.service |
4 | |
5 | [Service] |
6 | User=username |
7 | Group=username |
8 | Environment=AUTOSSH_GATETIME=0 |
9 | ExecStart=autossh \ |
10 | -NT \ |
11 | -o "ExitOnForwardFailure=yes" \ |
12 | -o "ServerAliveInterval=10" \ |
13 | -o "ServerAliveCountMax=3" \ |
14 | -M 9999 \ |
15 | -R '*:2424:localhost:22' \ |
16 | username@example.com |
17 | ExecStop=/usr/bin/killall -9 autossh |
18 | RestartSec=5 |
19 | Restart=always |
20 | |
21 | [Install] |
22 | WantedBy=multi-user.target |
Überall muß dazu natürlich <username> durch den gültigen Benutzernamen und <example.com> durch den DNS-auflösbaren Hostname Deines Servers oder durch dessen IP-Adresse ersetzt werden. Außerdem muß für den User <username> ein SSH-Schlüsselpaar mit ssh-keygen(1) erzeugt werden und sein öffentlicher Schlüssel auf dem Server in die Datei "$HOME/.ssh/authorized_keys" kopiert werden, damit der Login ohne Paßwort funktioniert. Für das Kopieren gibt es das Programm ssh-copy-id(1), dazu muß allerdings noch die Paßwort-Authentifizierung eingeschaltet sein. Wenn ssh-copy-id(1) den öffentlichen Schlüssel kopiert hat und der User und Du Euch ohne Paßworteingabe einloggen könnt, dann zur Verbesserung Eurer Sicherheit die Konfigurationsdirektive "PasswordAuthentication no" in die Datei /etc/ssh/sshd_config eingetragen und der SSH-Server restarten. Wenn diese Unit läuft, würde sie die Verbindung dauerhaft offenhalten, und dann bist Du von außen mit "ssh -p 2424 example.com" sofort da. Okay, die Verbindung soll nicht dauerhaft offen sein? Dann kannst Du den Kunden befähigen, sie bei Bedarf zu starten und zu stoppen, natürlich ohne ihm gleich Root-Zugang zu geben. Alles was es dazu braucht, ist eine kleine Datei in /etc/sudoers.d/username (remember, <username> ersetzen!) mit dem Inhalt:
1 | username hostname=(root:root) NOPASSWD: \ |
2 | /usr/bin/systemctl start autossh_username.service, \ |
3 | /usr/bin/systemctl stop autossh_username.service, \ |
4 | /usr/bin/systemctl is-active autossh_username.service, \ |
5 | /usr/bin/systemctl status autossh_username.service |
(Auch hier natürlich die Sache mit den Ersetzungen, zusätzlich <hostname> durch den hostnamen (nicht den FQDN) ersetzen. Die Subcommands "is-active" und "status" gibt es hier nur der Bequemlichkeit halber, dazu braucht der Benutzer keine Privilegien; der erste Befehl prüft ob der Service läuft; wenn ja, gibt er "active" aus und 0 zurück, wenn nein, gibt er "inactive" aus und etwas != 0 zurück, und "status" wirst Du ja sicherlich ohnehin schon längst kennen.) Dazu im Zweifel noch ein cleveres Shell- oder Pythonskript mit Desktop-, Startmenü- oder Programmstarter-Verknüpfungen, wenn Du Deinem User keine Shellbefehle zumuten möchtest, dann kann er das schick über Mausklicks starten, stoppen, und sich anzeigen lassen, ob der Tunnel läuft. Analog funktioniert das natürlich auch mit OpenVPN oder Wireguard. Mit diesen einfachen Tricks kannst Du die Maschine netzwerkseitig einfach mit DHCP ausliefern und kannst Dir den ganzen Krams mit der Konfiguration spezieller Dienste zum Starten eigener Netzwerk-Interfaces sparen... Wie auch immer: viel Spaß und Erfolg!
Angenommen, klassisches IPv4 Firmennetz. Das Ganze ist ein bekanntes mehrstufiges Problem: 1. IP Adresse im lokalen Netzwerk (das "L" in LAN) bekommen Dafür gibt es einen Zoo von Protokollen die unter der Überschrift "ZeroConf" (Zero-configuration networking) laufen. Aber, so richtig zu Ende gedacht wurden die nie. Wenn der Rechner nicht gerade in einer Firma von IT-mäßig degenerierten Eisenbiegern installiert wird, dann sind ZeroConf-Protokolle jetzt auch nicht gerade die Lieblinge der lokalen IT. Da will man nämlich Kontrolle drüber haben was so im eigenen Netzzwerk passiert. Für einige ZeroConf-Protokolle und verwandte Dienste muss auch eine gewisse Infrastruktur im LAN vorhanden sein. Daher würde ich nicht auf ZeroConf setzen. Die lokale IT hat zu entscheiden wie sie dem Ding eine lokale IP-Adresse verpasst. Zum Beispiel statisch konfiguriert oder mittels DHCP. Das muss der lokale ITler am Gerät auswählen können. ZeroConf-Protokolle kann man zwar auf dem Rechner aktiviert haben, aber eine lokale IT die was taugt wird nicht drauf setzen. Außer vielleicht um anfänglich mal Zugriff auf den Rechner zu bekommen. 2. Ausgehende Verbindungen (Rechner als Client) Darf der Rechner Verbindungen zu Servern im Internet aufbauen? Auch das entscheidet und konfiguriert letztendlich die lokale IT, und zwar komplett außerhalb des Rechners. Nämlich dadurch dass auf der Firewall ins Internet ausgehender Traffic (und welcher) erlaubt oder verboten wird. Da wird man wahrscheinlich eine Voreinstellung haben, aber egal was, das macht nicht der Rechner. Von anderen Lösungen, wie VPNs reden wir mal nicht. Auch das muss mit Hilfe der lokalen IT aufgebaut werden. 3. Eingehende Verbindungen (Rechner als Server) Hier gibt es was, nämlich den UPnP-Dreck und ähnliche Sicherheits- Alpträume, mit dem ein Rechner eine Firewall/NAT eigenständig konfigurier. Ein ITler der dass in einem Firmennetz zulässt ist die größte Pfeife vor dem Herren. Da würde ich nie im Leben drauf bauen. Fazit: Diese Idee, ich stell da einen Rechner hin, der sich magisch, auf Zuruf aus 12km Entfernung komplett konfiguriert ist illusorisch. Der Rechner hat von der lokalen IT ins Netz gebracht zu werden. Zuerst ins LAN, und sei es mit DHCP, dann ins WAN. Danach kann man darüber reden ob er sich automatisch weitere Konfigurationsinformationen von einem Server im Internet zieht.
Frank K. schrieb: > Bei IPv6 hast du immer auch Link-Local Adressen (fe80::...), die > aus der MAC-Adresse erzeugt werden. Hast Du die MAC, hast Du die > zugehörige IP. Die ist zwar nur in der aktuellen Broadcast Domain > erreichbar, aber das reicht ja oft auch. Damit musst Du nichts > umkonfigurieren, das ist eh immer da. Das Interface muss nur UP sein, dann funktioniert es sofort und immer. Das wäre doch die perfekte Lösung, jedenfalls für mich. Ja, bei diesem Rechner ist der MAC-Aufkleber natürlich innen und im eingebauten Zustand sind ca. 12 Schrauben im Weg. Aber sonst, wo ist der Fehler? Ein T. schrieb: > Was ich allerdings verstanden zu haben glaube, ist, daß es dabei um eine > Art (womöglich temporären) Fernwartungszugang gehen soll. Ist das > korrekt? Wenn ja, dann wäre mein Ansatz ein anderer -- entweder ein VPN > oder sogar ein einfacher SSH-Tunnel, den Dein Fernzuwartender optional > bei Bedarf starten und stoppen kann. Ja, tatsächlich wurde es früher so ähnlich gemacht, das funktioniert theoretisch einfach und übersichtlich, praktisch war es manchmal ein wenig umständlich. Hannes J. schrieb: > Dafür gibt es einen Zoo von Protokollen die unter der Überschrift > "ZeroConf" (Zero-configuration networking) laufen. > Aber, so richtig zu Ende gedacht wurden die nie. So ganz pauschal will ich ja ZeroConf, aber garantiert nicht mit avahi ;) > Darf der Rechner Verbindungen zu Servern im Internet aufbauen? Sehr unwahrscheinlich, weil unnötig. > Von anderen Lösungen, wie VPNs reden wir mal nicht. > Fazit: Der Rechner hat von der lokalen IT ins Netz gebracht zu werden. > Zuerst ins LAN, und sei es mit DHCP, dann ins WAN. Nicht unbedingt der Rechner, ein extra Service-Rechner geht auch, wahrscheinlich einfacher und mit mehr Möglichkeiten. Von dem aus funktioniert dann die Link Local Verbindung.
Bauform B. schrieb: > Ja, tatsächlich wurde es früher so ähnlich gemacht, das funktioniert > theoretisch einfach und übersichtlich, praktisch war es manchmal ein > wenig umständlich. Darf ich fragen, inwiefern das umständlich war? Vielleicht würde es sich wesentlich einfacher gestalten, die Umständlichkeit hinaus zu werfen, als eine esoterische Spezialkonstruktion zu basteln... :-) >> Darf der Rechner Verbindungen zu Servern im Internet aufbauen? > > Sehr unwahrscheinlich, weil unnötig. Der bekommt keine Updates? 8-O Edit: Update-Frage hinzugefügt.
:
Bearbeitet durch User
Ein T. schrieb: >>> Darf der Rechner Verbindungen zu Servern im Internet aufbauen? >> Sehr unwahrscheinlich, weil unnötig. > Der bekommt keine Updates? 8-O Man wünscht sich, dass der Rechner auch ohne jede Netzwerkverbindung funktioniert. Also müssen Updates per USB-Stick möglich sein. Also sind Updates jederzeit möglich, aber mangels Internet auch nicht so dringend. > Bauform B. schrieb: >> Ja, tatsächlich wurde es früher so ähnlich gemacht, das funktioniert >> theoretisch einfach und übersichtlich, praktisch war es manchmal ein >> wenig umständlich. > > Darf ich fragen, inwiefern das umständlich war? Vielleicht würde es sich > wesentlich einfacher gestalten, die Umständlichkeit hinaus zu werfen, > als eine esoterische Spezialkonstruktion zu basteln... :-) Umständlich war es, wenn ich erst jemand finden musste, der es bedient. Meine ursprüngliche Idee war sicher extrem, aber die Verbindung per Link Local ist doch die Lösung und sicher nicht esoterisch, ganz im Gegenteil.
:
Bearbeitet durch User
Was er ja eigentlich will ist dass sich die Rechner ohne Netzwerk-Config erstmal finden, und dann selber passend Konfigurieren. Also eigentlich DHCP, aber kein "echtes" DHCP, weil das nicht verwendet werden soll bzw. sich mit dem bereits vorhandenen DHCP im Netzwerk beißt. Wär' also z.B. eine einfache Lösung mit wenig Aufwand, auf den Rechnern DHCP auf einem Nicht-Standard-Port laufen zu lassen. (Option "-p xxxx" für dhcpd und dhclient) Bauform B. schrieb: > Auf dem Kabel gibt es (auch) ein Subnetz für mich, damit ist > auch das kein Problem: Insofern würde sich die Subnetze vom Firmen-DHCP und dem Zusatz-DHCP auch nicht stören. Dein DHCPd verwaltet einfach dein Subnetz, fertig.
Bauform B. schrieb: > Man wünscht sich, dass der Rechner auch ohne jede Netzwerkverbindung > funktioniert. Also müssen Updates per USB-Stick möglich sein. Also sind > Updates jederzeit möglich, aber mangels Internet auch nicht so dringend. Hm, vielleicht verstehe ich es ja nicht, aber... "jederzeit möglich" beißt sich doch ein wenig mit "USB-Stick", oder? Irgendwie müßte der Stick doch vorhanden und idealerweise halbwegs aktuell sein. Wäre da nicht eventuell sowas wie "unattended-upgrades" sinnvoll, gerade unter Debian? Das wäre doch sehr komfortabel: wenn das Netzwerk / Internet da ist, dann macht er seine Aktualisierungen, und wenn nicht, schreibt er eine Fehlermeldung in seine Logdateien und gut ist. > Umständlich war es, wenn ich erst jemand finden musste, der es bedient. Oh... dort gibt es niemanden, der bei Bedarf auf einen Knopf in einer GUI oder einem Webinterface drücken kann?
Ein T. schrieb: > Bauform B. schrieb: >> Man wünscht sich, dass der Rechner auch ohne jede Netzwerkverbindung >> funktioniert. Also müssen Updates per USB-Stick möglich sein. Also sind >> Updates jederzeit möglich, aber mangels Internet auch nicht so dringend. > > Hm, vielleicht verstehe ich es ja nicht, aber... "jederzeit möglich" > beißt sich doch ein wenig mit "USB-Stick", oder? "ohne jede Netzwerkverbindung" kann bedeuten, dass es auf dem Grundstück überhaupt nichts Netzwerk-ähnliches gibt, keine Telefonleitung, kein GSM. Also ist "jederzeit", wenn der Benutzer Zeit und Lust hat, da hin zu fahren und ein Update zu machen. Ganz allgemein macht man bei solchen Rechnern nur ungern Updates - Never touch a running system. Es gibt auch Installationen mit "normalem" Netzwerk, aber die sind von außen dermaßen nicht erreichbar. Da dauert ein Antrag auf einen offiziellen Service-Zugang Wochen, der Client braucht ein Dongle und vor lauter Sicherheit funktioniert das im Ernstfall nicht. Aus so einem Netzwerk heraus darf der Rechner natürlich auch nicht einfach so ins Internet. Und daran ist sowas schon mal gescheitert: > Wäre da nicht eventuell sowas wie "unattended-upgrades" sinnvoll, > gerade unter Debian? Debian arbeitet sicher sehr gewissenhaft, aber das riskiere ich dann doch nicht. >> Umständlich war es, wenn ich erst jemand finden musste, der es bedient. > Oh... dort gibt es niemanden, der bei Bedarf auf einen Knopf in einer > GUI oder einem Webinterface drücken kann? Selbst wenn der zufällig in der Nähe ist, muss ich erst telefonieren. Ich dachte halt, das muss doch auch komfortabler gehen.
(prx) A. K. schrieb: > Ist nicht so ungewöhnlich, wenn der Betreiber des Zielnetzes mit einer > Fernwartung explizit einverstanden ist und ggf per Firewall > kontrolliert. Stell ihn doch ins Tor / Darknet. Eigenes Relay + Keys für so etwas wie ein Subnet (Gammel-VPN) DURCH das Internet hindurch. "Family-Keys und Member" Da kannst du EINGEHENDE Verbindungen auf deinen Host per Port 80 u. 433 (für Fernwartungs-Software und Statusabfragen, "dein Knopf"), und auch Port 22 (für SSH auf die Konsole) direkt nutzen. DAS ALLES ABER OHNE Portforwarding oder Änderungen in zwischen liegenden Netzen, Firewalls oder Router(n). Ja Henne-Ei: Du brauchst trotzdem zuerst eine IP. --> War nur ein Scherz: Mach lieber ne "richtige" VPN, wenn du nachher nochmal drauf musst.
:
Bearbeitet durch User
Tim S. schrieb: > Stell ihn doch ins Tor / Darknet. (...) > Ja Henne-Ei: Du brauchst trotzdem zuerst eine IP. :) ja, irgendwas ist immer... Manchmal hilft es, wenn man rausfinden kann, ob man mit einem bekannten Netz verbunden ist. Dafür kann dann die vordefinierte Konfiguration geladen werden und in einem unbekannten Netz bleibt alles unkonfiguriert. Man muss nur ein paar Sekunden lauschen und nach Freund und Feind sortieren
1 | tcpdump -n -t -l -U -s 128 -i eth0 arp |
Aber das solideste sind immer noch DIL-Schalter oder Kodierstecker ;)
Bauform B. schrieb: > "ohne jede Netzwerkverbindung" kann bedeuten, dass es auf dem Grundstück > überhaupt nichts Netzwerk-ähnliches gibt, keine Telefonleitung, kein > GSM. das hat Stuxnet aber auch nicht gehindert eine SPS umzukonfigurieren
Alexander schrieb: > das hat Stuxnet aber auch nicht gehindert eine SPS umzukonfigurieren Das kam dann über Gehirnstrahlen aus dem Weltall. Dafür sind nämlich die GPS-Satelliten eigentlich da. Steht so im Internet, schwarz auf weiß.
Alexander schrieb: > das hat Stuxnet aber auch nicht gehindert eine SPS umzukonfigurieren Man sollte schon den Unterschied zwischen "kein (ungefilterter) Internetzugang" und "überhaupt kein Netzwerk" kennen. Stuxnet wurde zwar auf USB-Sticks reingeholt, der Rest lief aber über das Netzwerk.
Meine "Systemwiederherstellung" unter EndeavourOS ("Arch Linux") heißt:
Timeshift mit installiertem BTRFS Dateisystem.
X. H. schrieb: > Meine "Systemwiederherstellung" unter EndeavourOS ("Arch Linux") heißt: > Timeshift mit installiertem BTRFS Dateisystem. Und bei Arch-Linux braucht man das? Das spricht nicht gerade dafür. Falls dir das nicht klar sein sollte...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.