Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
— | anwenderwiki:linuxclient:fernsteuerung_linuxclient [2013/06/30 01:46] (aktuell) – angelegt - Externe Bearbeitung 127.0.0.1 | ||
---|---|---|---|
Zeile 1: | Zeile 1: | ||
+ | {{tag> | ||
+ | ====== Fernsteuerung/ | ||
+ | |||
+ | <note important> | ||
+ | **Nicht vergessen: | ||
+ | </ | ||
+ | |||
+ | ===== ... eines Linuxclients vom Server aus ===== | ||
+ | |||
+ | |||
+ | Folgende Problemstellungen können mit Hilfe einer Steuerung des Linuxclients über das Netzwerk gelöst werden: | ||
+ | |||
+ | * Zeitgesteuertes Herunterfahren am Ende des Arbeitstages | ||
+ | * Ein Hinweisfenster am Client einblenden. | ||
+ | * Zeitgesteuertes Sperren des Clients, z.B. in den Pausen | ||
+ | |||
+ | |||
+ | Vom Server lässt sich über ssh ein beliebiger Befehl auf dem Client ausführen. Dies wird z.B. bei der paedML benutzt um den IPCop fernzusteuern. Voraussetzung ist, dass der Client eine ssh-Anmeldung per Zertifikat akzeptiert. Am Client muss man ggf. zunächst den ssh-Server installieren und ihn so konfigurieren, | ||
+ | |||
+ | Dann muss man auf dem Client einen Public-Key ablegen, mit dem er Verbindungen von Server ohne Passworteingabe akzeptiert. Ein geeigneter Key ist der, der auch schon bei dem IPCop Verwendung findet. Diesen kopiert man nun auf den Linuxclient (hier mit Namen pc123) | ||
+ | |||
+ | # scp / | ||
+ | |||
+ | ACHTUNG: Falls die Datei authorized_keys am Client schon existiert, sollte man den Public-Key an diese Datei anhängen. | ||
+ | |||
+ | Nun sollte das folgende Einloggen vom Server auf den Client ohne Passworteingabe funktionieren: | ||
+ | | ||
+ | # ssh pc123 | ||
+ | |||
+ | ==== Client abschalten ==== | ||
+ | Jetzt kann man ohne Passworteingabe vom Server an den Client Befehle senden, z.B. zum Abschalten: | ||
+ | |||
+ | # ssh pc123 halt | ||
+ | |||
+ | oder automatisiert um 17.30, 18.30 und 19.30 Uhr als Eintrag in der Crontab des Servers: | ||
+ | |||
+ | 30 17, | ||
+ | |||
+ | ==== Hinweisfenster anzeigen ==== | ||
+ | Der Befehl **'' | ||
+ | |||
+ | # ssh pc123 /bin/cp / | ||
+ | # ssh pc123 / | ||
+ | |||
+ | Bei jedem Start des X-Servers wird die Datei " | ||
+ | |||
+ | | ||
+ | |||
+ | ==== Client sperren ==== | ||
+ | |||
+ | Um Clients z.B. in den großen Pausen zu sperren kann man den laufenden X-Server stoppen und einen neuen X-Server mit einem entsprechendem Hintergrundbild starten. Ein gerade angemeldeter User wird dabei sofort ohne Vorwarnung rausgeworfen. | ||
+ | Auf dem Client als root folgendes Script ausführen. Zusätzlich wird eine Uhr angezeigt. | ||
+ | |||
+ | #!/bin/bash | ||
+ | # script / | ||
+ | | ||
+ | / | ||
+ | | ||
+ | / | ||
+ | sleep 3 | ||
+ | / | ||
+ | sleep 3 | ||
+ | export DISPLAY=:1 | ||
+ | / | ||
+ | / | ||
+ | | ||
+ | exit 0 | ||
+ | |||
+ | Die Datei **'' | ||
+ | |||
+ | Zum Reaktivieren des Anmeldefensters (Prozess " | ||
+ | |||
+ | #!/bin/bash | ||
+ | # script / | ||
+ | | ||
+ | / | ||
+ | | ||
+ | / | ||
+ | sleep 3 | ||
+ | / | ||
+ | sleep 3 | ||
+ | / | ||
+ | | ||
+ | exit 0 | ||
+ | |||
+ | Die Scripte können jeweils vom Server per ssh am Client gestartet werden. Man legt dazu die beiden Scripte unter **''/ | ||
+ | |||
+ | # ssh pc123 / | ||
+ | # ssh pc123 / | ||
+ | |||
+ | ===== ... von Webdiensten (Webmin, IPCop, Schulkonsole, | ||
+ | siehe hier: http:// | ||
+ | |||
+ | **Erläuterung für Dummys ;-) von //Holger B.// zu dem Thema:** | ||
+ | |||
+ | **Frage** aus der Linuxmuster-Mailingliste: | ||
+ | "Doch mir ist vor allem nicht klar, wie ich mit dem ssh Ungetüm, anschließend im Browser die Schulkonsole per https:// | ||
+ | |||
+ | |||
+ | **Antwort**: | ||
+ | "Genau so geht das! - Wir stellen uns ein Rohr vor, von einem Haus zum anderen. Das soll die SSH Sitzung sein. Durch dieses Rohr, welches bei mir ZUhause auf dem Rechner anfängt und auf dem Schulserver endet, lege ich nun mehrere Kabel (tunnel). Die Enden der Kabel kann ich an verschiedenen Stellen fest machen z.B. 10.16.1.254: | ||
+ | Nun muß ich die zugehörigen Enden bei mir Zuhause noch fest machen. | ||
+ | Dafür wähle ich die Ports 8800 und 8801. | ||
+ | Wenn ich jetzt des Browsers Ohr an http:// | ||
+ | |||
+ | Man kann den lokalen Port selber wählen. Man sollte nur keinen Port nehmen, auf dem schon ein Protokoll läuft (80 oder 443 oder 22 oder 21 ...) also nimmt man 8000 + x | ||
+ | |||
+ | Hier ist meine // | ||
+ | |||
+ | # /bin/bash | ||
+ | ssh -p 2222 -i / | ||
+ | |||
+ | **Hinweise: | ||
+ | Falls bei Aufruf des // | ||
+ | |||
+ | Wenn //kein Zertifikat// | ||
+ | |||
+ | Horde und Nagios benötigen den https-Port 443, d.h., man ruft sie dann im Browser zuhause per https:// | ||
+ | https:// | ||
+ | |||
+ | Andere Server erreiche ich auch gleichzeitig noch, aber natürlich mappe ich dafür die remote-Ports woanders hin. | ||
+ | Ganz wichtig sind dann noch die Bookmarks im Firefox, damit man sich die lokalen Ports nicht alle merken muss. | ||
+ | |||
+ | //-L 5900// ist der VNC eines Windowsservers bei uns im Grünen Netz, d.h., ich tunnel mir auch noch VNC auf einen Windowsserver, | ||
+ | So hab ich mir auch schon das Webfrontend eines 3com-Switches nach Hause " | ||
+ | |||
+ | **Wichtig**: | ||
+ | |||
+ | //SSH// -> einzelne Ports lokal erscheinen lassen --- \\ | ||
+ | //VPN// -> ein ganzes Netzwerk routen. | ||
+ | |||
+ | Bei openVPN wird, anders als bei SSH, ein Tunnel, sozusagen ein dickes Rohr, erstellt und der gesammte Netzwerkverkehr (wenn man will) durch diesen Tunnel geleitet, während bei SSH durch die bestehende SSH Verbindung einzelne Zielports auf lokale Ports abgebildet werden. Deswegen muß mann bei VPN keine einzelnen Ziel-IPs bzw. ZielPorts angeben. Man befindet sich da sozusagen schon direkt im Grünen Netz. \\ | ||
+ | Im eigenen Router zuhause ist bei VPN und SSH nichts zu tun. Im remote-Router, | ||
+ | |||
+ | Neuere SSH-Versionen können auch die default route auf den Tunnelendpunkt setzen und fungieren dann als " | ||
+ | |||
+ | |||
+ | ===== ... eines Windowsclients im Grünen Netz per VNC via SSH-Tunnel von außen ===== | ||
+ | Wie geht das genau? | ||
+ | |||
+ | Genau so, wie hier oberhalb beschrieben bei den einzelnen Ports auf dem Server oder IPCop, nur gibt man als IP nicht die des Servers oder IPCops an, sondern die des Windowsservers im Grünen Netz. Auf dem muss man natürlich vorher VNC bzw. VNC-Server installiert haben - ich verwende realVNC (-> google) - und in dessen Firewall der Port 5900 frei ist bzw. durchlässig geschaltet sein muss. | ||
+ | Zum Testen versucht man erst einmal von einem anderen Client des Grünen Netzes aus mit dem VNC-Client bzw. VNC-Viewer auf diesen VNC-Server zuzugreifen. Der VNC-Betrachter läuft ohne Installation, | ||
+ | |||
+ | Wenn das funktioniert, | ||
+ | |||
+ | Bei mir zuhause unter Ubuntu in meinem Verbindungsscript (s.o.) sieht das dann so aus: | ||
+ | |||
+ | -L 5900: | ||
+ | |||
+ | Port 5900 des Windowsservers (10.18.126.100) wird also auf meinen lokalen Port 5900 getunnelt. | ||
+ | |||
+ | Ich benötige den realVNC-Clienten bzw. -Viewer zuhause nicht, weil mein dort benutztes Ubuntu den " | ||
+ | |||
+ | Das Ganze kann man auch mit RDP (Remote Desktop Protokol) von Microsoft machen. | ||
+ | Der Vorteil ist, dass es schon bei Windows dabei ist und schlanker sein soll als VNC. | ||
+ | Ich verwende VNC, weil ich damit schon Erfahrung hatte. \\ | ||
+ | |||
+ | ===== .... auf den Dateimanager in horde und damit Zugriff auf das Serverhomeverzeichnis von außen ===== | ||
+ | |||
+ | Über den Dateimanager in horde3 unter "Mein Konto" können KollegInne von zuhause aus an ihre Serverhomeverzeichnisse kommen! Dazu muss https (Port TCP/443) auch über IPCop und ggf. vorgeschalteten Router ins Internet freigegeben werden. | ||