Benutzer-Werkzeuge

Webseiten-Werkzeuge


 [[anwenderwiki:linuxclient:fernsteuerung_linuxclient]] 

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

anwenderwiki:linuxclient:fernsteuerung_linuxclient [2013/06/29 23:46]
anwenderwiki:linuxclient:fernsteuerung_linuxclient [2013/06/29 23:46] (aktuell)
Zeile 1: Zeile 1:
 +{{tag>​extern linuxclient fernsteuerung remote ssh windowsclient putty webdienste webmin ipcop schulkonsole cups nagios horde}}
 +====== Fernsteuerung/​Fernzugriff .... ======
 +
 +<note important>​
 +**Nicht vergessen:​** Ist ein **Hardwarerouter** dem Server **vorgeschaltet**,​ muss **für den Zugriff von außen** in diesem Router die **Portweiterleitung** TCP/1194 für eine OpenVPN-Verbindung und/oder TCP/2222 für das SSH-Tunneln zum Server/​IPCOP eingeschaltet werden! **Wichtig**:​ Nicht //​ssh-Tunneln//​ und //openVPN// durcheinanderwürfeln - Erläuterung der Unterschiede siehe weiter unten. Aufpassen bei Copspot-Verwendung s.u.
 +</​note>​
 +
 +===== ... 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,​ dass sich root anmelden darf.
 +
 +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 /​root/​.ssh/​id_dsa.pub root@pc123:/​root/​.ssh/​authorized_keys
 +
 +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,​18,​19 ​ *  *  *   /​usr/​bin/​ssh pc123 halt >> /dev/null
 +
 +==== Hinweisfenster anzeigen ====
 +Der Befehl **''​zenity''​** erzeugt auf dem Desktop des Ubuntu-PC'​s ein grafisches Fenster mit einem Hinweistext (siehe auch Manpage zu zenity). Dazu muss aber eine Verbindung zum X-Server des Desktops aufgebaut werden und dafür eine Authentifizierung des users root stattfinden. Dies geschieht durch die Datei "​**''​.Xauthority''​**",​ die in das home von root kopiert werden muss. 
 +
 +  # ssh pc123 /bin/cp /​var/​lib/​gdm/:​0.Xauth ​ /​root/​.Xauthority
 +  # ssh pc123 /​usr/​bin/​zenity --warning --text='​Dieser PC wird in 3 Minuten abgeschaltet.'​ --display=:​0 &
 +
 +Bei jedem Start des X-Servers wird die Datei "​**'':​0.Xauth''​**"​ neu erzeugt und muss deshalb jedesmal kopiert werden. Das Zeichen "''&''"​ am Ende eines Befehls bewirkt, dass nicht gewartet wird, bis der Befehl beendet bzw. das grafische Fenster geschlossen wird. 
 +
 +    ​
 +
 +==== 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 /​root/​bin/​sperren.ein ​
 +    ​
 +  /​usr/​bin/​pgrep gdm || exit 0
 +  ​
 +  /​usr/​bin/​pkill gdm
 +  sleep 3
 +  /​usr/​bin/​X11/​X :1 &
 +  sleep 3
 +  export DISPLAY=:1
 +  /​usr/​bin/​X11/​xsetroot -bitmap "/​root/​gesperrt.xbm"​
 +  /​usr/​bin/​X11/​xclock -geometry 300x300-20+20 -update 1 &
 +  ​
 +  exit 0
 +
 +Die Datei **''​gesperrt.xbm''​** muss ein X-Windows-Bitmap enthalten, ein normales Bitmap funktioniert nicht.  ​
 +
 +Zum Reaktivieren des Anmeldefensters (Prozess "​gdm"​) dann folgendes Script ausführen:
 +
 +  #!/bin/bash
 +  # script /​root/​bin/​sperren.aus
 +    ​
 +  /​usr/​bin/​pgrep gdm && exit 0
 +  ​
 +  /​usr/​bin/​pgrep X && pkill X
 +  sleep 3
 +  /​usr/​bin/​pgrep gdm && pkill gdm 
 +  sleep 3
 +  /​usr/​bin/​gdm
 +  ​
 +  exit 0
 +
 +Die Scripte können jeweils vom Server per ssh am Client gestartet werden. Man legt dazu die beiden Scripte unter **''/​root/​bin/''​** am Ubuntu-Client ab und ruft diese dann vom Server auf:
 +
 +  # ssh pc123 /​root/​bin/​sperren.ein &
 +  # ssh pc123 /​root/​bin/​sperren.aus &
 +
 +===== ... von Webdiensten (Webmin, IPCop, Schulkonsole,​ Cups, Nagios, Horde etc.) per SSH-Tunnel von außen =====
 +siehe hier: http://​lehrerfortbildung-bw.de/​netz/​muster/​linux/​material/​remote/​doc/​tunnel/​
 +
 +**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://​127.0.0.1:​242 aufrufen können soll??? Also durch FritzBox - Internet - Draytek-DSL-Router - IPCop - Server die Schulkonsole erhalten?"​
 +
 +
 +**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:​445 und 10.16.1.1:​242
 +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://​127.0.0.1:​8800 lauschen lasse, so landet der Browser in der Schule auf dem IPCop und zeigt mir die Seite an. Ebenso mit der Schulkonsole unter https://​127.0.0.1:​8801
 +
 +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 //​ssh-Batch-/​Scriptdatei//​ dafür, eine Textdatei, die ich unter Ubuntu auf dem Desktop liegen, nach dem Erstellen via rechte Maustaste ausführbar gemacht und meineschule.sh genannt habe:
 +
 +  # /bin/bash
 +  ssh -p 2222 -i /​home/​baumho/​.ssh/​id_rsa -L 8880:​10.16.1.1:​80 -L 8881:​10.16.1.1:​443 -L 8882:​10.16.1.1:​631 -L 8883:​10.16.1.1:​242 -L 8884:​10.16.1.254:​445 -L 8110:​10.16.1.1:​1 -L 5900:​10.18.126.100:​5900 -L 8999:​10.16.1.1:​999 -L 8885:​10.16.1.1:​110 root@meineschule.dynalias.org
 +
 +**Hinweise:​** \\
 +Falls bei Aufruf des //​Cups-Webfrontend//​ (888x:​10.16.1.1:​631) ein //Fehler "​Forbidden 403"// im Browser erscheint, muss noch in der Datei //​etc/​cupsd.conf//​ an drei Stellen unter //Allow 10.*// die Zeile //Allow 172.16.18.*//​ oder in ///​etc/​cups/​access.conf//​ bei allen Druckern ein //Allow from 172.16.18.*//​ eingetragen werden. Danach Cups mit //​etc/​init.d/​cupsys restart// neu starten. ​ \\
 +
 +Wenn //kein Zertifikat//​ verwendet wird, kannst man sich //-i /blabla// sparen. ​
 +
 +Horde und Nagios benötigen den https-Port 443, d.h., man ruft sie dann im Browser zuhause per https://​127.0.0.1:​888x/​nagios2
 +https://​127.0.0.1:​888x/​horde3 auf (888x = freigewählter lokaler Port im Bereich 8000 + x)
 +
 +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,​ der im Grünen Netz steht ... feine Sache das :-)
 +So hab ich mir auch schon das Webfrontend eines 3com-Switches nach Hause "​verlegt"​. Spart ein Haufen sprit. (Siehe nächstes Thema weiter unten!)
 +
 +**Wichtig**:​ Nicht //ssh// mit //openVPN// durcheinanderwürfeln:​
 +
 +//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,​ falls also ein Hardwarerouter in der Schule vor dem Server läuft, muss für SSH der Port TCP/2222 auf den IPCop weitergeleitet werden. Im IPCop wird der Port 2222 dann per Standardeinstellung auf den Port 22 am Server weitergeleitet. Bei openVPN ist es der Port 1194 (UDP). Aber **Achtung: Verwendet man jeoch den CopSpot** und möchte trotzdem VPN auf den Server machen, muss man VPN (UDP) vorher auf 1194 (TCP) umstellen. Wie das geht, steht bei der Copspot-Installationsanleitung im Wiki.
 +
 +Neuere SSH-Versionen können auch die default route auf den Tunnelendpunkt setzen und fungieren dann als "​quasiVPN"​. (siehe auch eine Ausgabe der ct in 2008)
 +
 +
 +===== ... 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,​ kann also einfach auf einen beliebigen Clienten, von dem aus man auf den Server zugreifen möchte, kopiert und gestartet werden. In das aufgehende Abfragefenster muss man dann die IP des VNC-Server-PCs und das dort beim VNC-Server eingegebene Passwort eingeben, bevor die Verbindung hergestellt werden kann.
 +
 +Wenn das funktioniert,​ kann man zuhause einen weiteren Tunnel in SSH definieren (s.o.) mit dem Port 5900 und der IP des Windowsservers,​ den man erreichen will. Auf diesem VNC-Server-PC läuft bei mir ein einfaches Windows XP pro.
 +
 +Bei mir zuhause unter Ubuntu in meinem Verbindungsscript (s.o.) sieht das dann so aus: 
 +   
 +   -L 5900:​10.18.126.100:​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 "​Betrachter für entfernte Desktops"​ und "​Terminalserver Client"​ bereits mitbringt, die beide auch das VNC-Protokoll können.
 +
 +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.
  
 [[anwenderwiki:linuxclient:fernsteuerung_linuxclient]] anwenderwiki/linuxclient/fernsteuerung_linuxclient.txt · Zuletzt geändert: 2013/06/29 23:46 (Externe Bearbeitung)