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

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

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.

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 &

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)

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.

Ü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.