Fernwartung: Unterschied zwischen den Versionen

Aus Mikiwiki
Zur Navigation springen Zur Suche springen
Keine Bearbeitungszusammenfassung
Keine Bearbeitungszusammenfassung
 
(19 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
Als <b>Fernwartung</b> (auch: Remote-Support) wird der Fernzugriff von technischem Personal auf Systeme zu Wartungs- und Reparaturzwecken. Neben Telefon- und Industrieanlagen werden zunehmend auch [[Rechner]] aus der Ferne gewartet.
Als <b>Fernwartung</b> (auch: Remote-Support) wird der Fernzugriff von technischem Personal auf Systeme zu Wartungs- und Reparaturzwecken. Neben Telefon- und Industrieanlagen werden zunehmend auch [[Rechner]] aus der Ferne gewartet.


== Möglichkeiten ==
== Konfiguration ==


Einer der häufigsten Hinderungsgründe für Fernwartung liegt in den NAT-Routern, hinter denen sich inzwischen viele Rechner verbergen. Diese verhindern den direkten Zugriff auf den entfernten Rechner, selbst wenn die IP-Adresse bekannt wäre. Die folgende Rechnernetzstruktur zeigt einen Rechner hinter einem Router mit Firewall und bildet das in privaten Haushalten übliche Szenario ab.
Einer der häufigsten Hinderungsgründe für Fernwartung liegt in den NAT-Routern, hinter denen sich inzwischen viele Rechner verbergen. Diese verhindern den direkten Zugriff auf den entfernten Rechner, selbst wenn die IP-Adresse bekannt wäre. Die folgende Rechnernetzstruktur zeigt einen Rechner hinter einem Router mit Firewall und bildet das in privaten Haushalten übliche Szenario ab.
Zeile 17: Zeile 17:
* Vom Rechner des Benutzers aus wird ein Reverse-SSH-Tunnel zum Rechner des Technikers aufgebaut und somit der Port, auf dem der VNC-Server lauscht, auf den Rechner des Technikers umgeleitet.
* Vom Rechner des Benutzers aus wird ein Reverse-SSH-Tunnel zum Rechner des Technikers aufgebaut und somit der Port, auf dem der VNC-Server lauscht, auf den Rechner des Technikers umgeleitet.
* Herstellung einer Verbindung mit dem VNC-Client-Server, sodass der Rechner des Benutzers gesteuert werden kann.
* Herstellung einer Verbindung mit dem VNC-Client-Server, sodass der Rechner des Benutzers gesteuert werden kann.
In einem ersten Schritt wird dabei die SSH-Verbindung aufgebaut:
<pre class=wiki>
|-------------|      |------------------|                      |------------|      |-------------|
| Rechner des | ----- | NAT-Router      | ----- INTERNET ----- | NAT-Router | ----- | Rechner des |
| Technikers  |      | (IP-Adresse über |                      |------------|      | Benutzers  |
|-------------|      | Dyndns bekannt)  |                                          |-------------|
                      |------------------|
      Router leitet  <--------            <----- Shellskript baut SSH-Tunnel zur Dyndns-Adresse auf
      Anfrage weiter
</pre>
im zweiten Schritt wird der Reverse-SSH-Tunnel aufgebaut:
<pre class=wiki>
|-------------|      |------------------|                      |------------|      |-------------|
| Rechner des | ----- | NAT-Router      | ----- INTERNET ----- | NAT-Router | ----- | Rechner des |
| Technikers  |      | (IP-Adresse über |                      |------------|      | Benutzers  |
|-------------|      | Dyndns bekannt)  |                                          |-------------|
                      |------------------|
      Router leitet  <--------            <----- Shellskript baut SSH-Tunnel zur Dyndns-Adresse auf
      Anfrage weiter
  ---------- Port 10823 auf dem Rechner des Technikers wird über die SSH-Verbindung auf -------->
            Port 5900 des Benutzers weitergeleitet
</pre>


Auf dem Rechner des Benutzers sind dazu erforderlich:
Auf dem Rechner des Benutzers sind dazu erforderlich:
* ein VNC-Server (z. B. Vino unter Gnome oder [http://docs.kde.org/stable/en/kdenetwork/krfb/ KRFB] unter KDE).
* ein VNC-Server (z. B. Vino unter Gnome oder [http://docs.kde.org/stable/en/kdenetwork/krfb/ KRFB] bzw. KRDC unter KDE).
* ein SSH-Client (am besten [[ssh]]).
* ein SSH-Client (am besten [[ssh_(Shell-Befehl)|ssh]]).
* ein Shellskript, das den VNC-Server und den SSH-Client richtig konfiguriert.
* ein Shellskript, das den VNC-Server und den SSH-Client richtig konfiguriert.
Auf dem Rechner des Technikers sind erforderlich:
* ein VNC-Client.
* ein SSH-Server.
* eine bekannte (nicht unbedingt feste) [[IP-Adresse]].
=== Beispielkonfiguration ===
# Der Techniker konfiguriert sein Rechnernetz so, dass der SSH-Client des Benutzers eine Verbindung herstellen kann.
## Ermittlung der öffentlichen IP-Adresse des Rechners des Technikers (z. B. über http://checkip.dyndns.org/)
## Praktisch ist auch ein [[Dyndns]]-Konto. Dann kommt im folgenden Shellskript "remotesupport.sh" anstelle der ermittelten IP-Adresse die Dyndns-URL zum Einsatz, sodass das Skript nicht jedesmal neu erstellt werden muss. Im Beispiel wird angenommen, dass das Dyndns-Konto "techniker.dyndns.org" zur Verfügung steht.
# Die Konfiguration des Routers des Technikers wird so geändert, dass dieser den Port 22 auf den Port 22 des Rechners des Technikers weiterleitet. Je nach Router kann diese Einstellung "Portforwarding", "Exposed Host" oder "Virtual Server" heissen.
# Konfiguration des Rechners des Technikers.
## Installation eines SSH-Servers, am besten Openssh.
## Benutzerkonto zur Verwendung des Reverse-SSH-Tunnels.
## Installation eines VNC-Clients.
## Konfiguration des SSH-Servers, der Benutzer anhand eines Public Keys identifizieren können muss.
### Anpassung der Datei "/etc/ssh/sshd_config", wo die Variable "PubkeyAuthentication yes" gesetzt werden muss.
### Neustart des SSH-Servers mittels "sudo etc/init.d/ssh restart".
## Erstellen des Benutzers "remotesupport" mittels "sudo useradd -m -d /home/remotesupport -s /bin/false remotesupport".
## Erstellen des Passworts für Benutzer "remotesupport" mittels "sudo passwd -l remotesupport".
## Erzeugen eines Schlüsselpaars für den Zugang durch Aufruf von "ssh-keygen" als Benutzer "remotesupport".
## Damit der SSH-Server den Schlüssel erkennt, wird als Benutzer "remotesupport" der Befehl "cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys" ausgeführt.
# Konfiguration des Rechners des Benutzers; hier werden nur temporär einige Parameter umgestellt. Das Umstellen könnte auch der Benutzere selbst erledigen, dabei können sich jedoch Fehler einschleichen, weswegen ein Shellskript dafür besser geeignet ist. Das Shellskript "remotesupport.sh" sorgt für den Aufbau des SSH-Tunnels. Dazu muss sich der SSH-Client ohne Passwort und ohne weiteres Zutun am Rechner des Technikers anmelden können, um einen Reverse-SSH-Tunnel zu öffnen.
## Der Befehl für den Reverse-SSH-Tunnel lautet wie folgt. Mit dem Schalter "-R" bittet der SSH-Client dabei beim SSH-Server um eine Weiterleitung. Der SSH-Server lauscht dann auf Port 10823 und leitet alle Daten, welche der SSH-Client dorthin schreibt, durch den SSH-Tunnel zum Port 5900 des Rechners des Benutzers weiter - damit gelangen später die Anfragen vom VNC-Client des Technikers an den VNC-Server des Benutzers. Der zweite Schalter "-R" baut zusätzlich einen zweiten SSH-Tunnel auf, welcher den Port 10285 auf den allenfalls vorhandenen SSH-Server (Port 22) des Rechners des Benutzers weiterleitet.<br><tt>$ <b>ssh -i $PREFIX/privatekey -N remotesupport@techniker.dyndns.org -R 10823:localhost:5900 -R 10285:localhost:22</b></tt>
## Damit der Rechner des Technikers erkannt wird, wird der Hostkey des Rechners des Technikers in die Datei "~/.ssh/known_hosts" eingefügt. Mit dem Befehl "ssh-keyscan" erfolgt das auf einfache Weise (siehe das untenstehende Shellskript "remotesupport.sh").
## Der passende private Schlüssel wird ebenfalls auf dem Rechner des Benutzers abgelegt - das Shellskript "remotesupport.sh" wird ihn also gleich mitliefern.
Der erste Teil des bereits erwähnten Shellskripts "remotesupport.sh" sieht wie folgt aus:
#!/bin/bash
# Arbeitsverzeichnis zum Ablegen temporärer Daten.
PREFIX=/tmp/remotesupport
mkdir $PREFIX
# SSH-Verzeichnis erstellen.
if [ ! -f ~/.ssh/known_hosts ]; then
  mkdir ~/.ssh
  chmod 0700 ~/.ssh
fi
# Sicherung der Datei "known_hosts" zum späteren Wiederherstellen.
cp ~/.ssh/known_hosts $PREFIX/known_hosts
# Serverschlüssel kopieren.
ssh-keyscan -t dsa techniker.dyndns.org >> ~/.ssh/known_hosts
ssh-keyscan -t rsa techniker.dyndns.org >> ~/.ssh/known_hosts
# Privaten Schlüssel aus dem Skript schreiben.
# Alles bis zwischen den EOFs landet in der Ausgabedatei.
cat > $PREFIX/privatekey << EOF
-----BEGIN RSA PRIVATE KEY-----
...
-----END RSA PRIVATE KEY-----
EOF
# Zugriffsrechte richtig setzen.
chmod 0600 $PREFIX/privatekey
# Öffnen der SSH-Verbindung.
ssh -i $PREFIX/privatekey -N remotesupport@techniker.dyndns.org \
  -R 10823:localhost:5900 -R 10285:localhost:22 &
Im nächsten Abschnitt des Skripts "remotesupport.sh" wird der VNC-Server gestartet, damit der Techniker wirklich Zugriff auf die Arbeitsoberfläche des Benutzers erhält. Sowohl [[Gnome]] wie [[KDE]] liefern standardmässig einen VNC-Server mit, dieser ist allerdings weder konfiguriert noch aktiviert. Das Skript prüft also, welches der beiden Programme Vino (Gnome) oder KRFB (KDE) sich auf dem Rechner des Benutzers befindet:
ISTGNOME=$(which vino-preferences | wc -l)
ISTKDE=$(which krfb | wc -l)
# Gnome-Arbeitsoberfläche
if [ $ISTGNOME -eq 1 ]; then
  # Aktuelle Konfiguration sichern
  gconftool-2 --dump /desktop/gnome/remote_access > $PREFIX/vino_set
  # Neue Konfiguration erstellen
  gconftool-2 -s -t bool /desktop/gnome/remote_access/enabled true
  gconftool-2 -s -t bool /desktop/gnome/remote_access/local_only false
  gconftool-2 -s -t bool /desktop/gnome/remote_access/prompt_enabled false
  gconftool-2 -s -t bool /desktop/gnome/remote_access/view_only false
fi
# KDE-Arbeitsoberfläche
<nowiki>if [[ $HAVEVINO -eq 0 && $HAVEKRFB -eq 1 ]]; then</nowiki>
  # Aktuelle Konfiguration sichern
  cp ~/.kde/share/config/krfbrc $PREFIX/krfbrc_set
  # Neue Konfiguration erstellen
  cat > ~/.kde/share/config/krfbrc << EOF
allowDesktopControl=true
allowUninvited=true
confirmUninvitedConnection=false
disableBackground=true
disableXShm=false
enableSLP=false
preferredPort=5900
uninvitedPasswordCrypted=
[invitations]
invitation_num=0
EOF
  # KRFB muss einmal kurz gestartet werden, damit die Konfiguration
  # übernommen wird. Der Benutzer sieht dabei ein kleines Fenster, das sich
  # nach einer Sekunde wieder schliesst.
  krfb &
  sleep 1
  killall krfb
fi
Mit dem Skript "remotesupport.sh" wird also eine SSH-Verbindung hergestellt und ein VNC-Server auf dem Rechner des Benutzers gestartet. Der Techniker kann sich danach mit seinem VNC-Client auf den Socket "localhost:10283" verbinden und sieht die Arbeitsoberfläche des Benutzers.
Der Ordnung halber wird das Skript "remotesupport.sh" noch etwas erweitert, damit es nach Schliessen des SSH-Tunnels aufräumt. Dabei wird die Prozessliste nach dem Tunnelprozess durchsucht. Im Erfolgsfall wartet das Skript drei Sekunden und sucht erneut. Wird der Tunnelprozess nicht gefunden, so wird die Schleife beendet und das Skript läuft weiter. Anschliessend folgen noch einige Aufräumarbeiten.
SSHRUNNING=$(ps ax | \
  grep 'ssh -i $PREFIX/privatekey -N remotesupport@techniker.dyndns.org -R 10823:localhost:5900 -R 10285:localhost:22' | \
  grep -v grep | wc -l)
while [ $SSHRUNNING -gt 0 ]
  do
  SSHRUNNING=$(ps ax | \
    grep 'ssh -i $PREFIX/privatekey -N remotesupport@techniker.dyndns.org -R 10823:localhost:5900 -R 10285:localhost:22' | \
    grep -v grep | wc -l)
  sleep 3
  done
# Datei "known_hosts" wiederherstellen.
mv $PREFIX/known_hosts ~/.ssh/known_hosts
# VNC-Konfiguration wiederherstellen.
if [ $ISTGNOME -eq 1 ]; then
  gconftool-2 --load $PREFIX/vino_set
fi
<nowiki>if [[ $ISTGNOME -eq 0 && $ISTKDE -eq 1 ]]; then</nowiki>
  mv $PREFIX/krfbrc_set ~/.kde/share/config/krfbrc
  krfb &
  sleep 1
  killall krfb
fi
# Löschen des temporären Verzeichnisses.
rm -rf $PREFIX
Braucht nun jemand die Unterstützung des Technikers, so schickt dieser dem Benutzer einfach die Datei "remotesupport.sh". Der Benutzer braucht die Datei bloss ausführbar zu machen und anschliessend auszuführen.
Der Techniker sollte den Benutzer "remotesupport" nach getaner Arbeit auf seinem Rechner wieder sperren und das Portforwarding abschalten, damit der Rechner nicht mehr von aussen erreichbar ist.


== Weblinks ==
== Weblinks ==


{{Weblinks1|{{url_dewikipedia|Fernwartung|Fernwartung}}
{{Weblinks}}
}}
{{url_dewikipedia|Fernwartung|Fernwartung}}
{{Fuss}}




{{cat|Systemverwaltung}}
{{cat|Systemverwaltung}}

Aktuelle Version vom 8. Februar 2010, 18:33 Uhr

Als Fernwartung (auch: Remote-Support) wird der Fernzugriff von technischem Personal auf Systeme zu Wartungs- und Reparaturzwecken. Neben Telefon- und Industrieanlagen werden zunehmend auch Rechner aus der Ferne gewartet.

Konfiguration

Einer der häufigsten Hinderungsgründe für Fernwartung liegt in den NAT-Routern, hinter denen sich inzwischen viele Rechner verbergen. Diese verhindern den direkten Zugriff auf den entfernten Rechner, selbst wenn die IP-Adresse bekannt wäre. Die folgende Rechnernetzstruktur zeigt einen Rechner hinter einem Router mit Firewall und bildet das in privaten Haushalten übliche Szenario ab.

|-------------|       |------------------|                      |------------|       |-------------|
| Rechner des | ----- | NAT-Router       | ----- INTERNET ----- | NAT-Router | ----- | Rechner des |
| Technikers  |       | (IP-Adresse über |                      |------------|       | Benutzers   |
|-------------|       | Dyndns bekannt)  |                                           |-------------|
                      |------------------|

Die Fernwartung ist in folgender Art möglich:

  • Auf dem Rechner des Benutzers wird ein VNC-Server aktiviert.
  • Vom Rechner des Benutzers aus wird ein Reverse-SSH-Tunnel zum Rechner des Technikers aufgebaut und somit der Port, auf dem der VNC-Server lauscht, auf den Rechner des Technikers umgeleitet.
  • Herstellung einer Verbindung mit dem VNC-Client-Server, sodass der Rechner des Benutzers gesteuert werden kann.

In einem ersten Schritt wird dabei die SSH-Verbindung aufgebaut:

|-------------|       |------------------|                      |------------|       |-------------|
| Rechner des | ----- | NAT-Router       | ----- INTERNET ----- | NAT-Router | ----- | Rechner des |
| Technikers  |       | (IP-Adresse über |                      |------------|       | Benutzers   |
|-------------|       | Dyndns bekannt)  |                                           |-------------|
                      |------------------|

      Router leitet  <--------             <----- Shellskript baut SSH-Tunnel zur Dyndns-Adresse auf
      Anfrage weiter 

im zweiten Schritt wird der Reverse-SSH-Tunnel aufgebaut:

|-------------|       |------------------|                      |------------|       |-------------|
| Rechner des | ----- | NAT-Router       | ----- INTERNET ----- | NAT-Router | ----- | Rechner des |
| Technikers  |       | (IP-Adresse über |                      |------------|       | Benutzers   |
|-------------|       | Dyndns bekannt)  |                                           |-------------|
                      |------------------|

      Router leitet  <--------             <----- Shellskript baut SSH-Tunnel zur Dyndns-Adresse auf
      Anfrage weiter

  ---------- Port 10823 auf dem Rechner des Technikers wird über die SSH-Verbindung auf -------->
             Port 5900 des Benutzers weitergeleitet


Auf dem Rechner des Benutzers sind dazu erforderlich:

  • ein VNC-Server (z. B. Vino unter Gnome oder KRFB bzw. KRDC unter KDE).
  • ein SSH-Client (am besten ssh).
  • ein Shellskript, das den VNC-Server und den SSH-Client richtig konfiguriert.

Auf dem Rechner des Technikers sind erforderlich:

  • ein VNC-Client.
  • ein SSH-Server.
  • eine bekannte (nicht unbedingt feste) IP-Adresse.

Beispielkonfiguration

  1. Der Techniker konfiguriert sein Rechnernetz so, dass der SSH-Client des Benutzers eine Verbindung herstellen kann.
    1. Ermittlung der öffentlichen IP-Adresse des Rechners des Technikers (z. B. über http://checkip.dyndns.org/)
    2. Praktisch ist auch ein Dyndns-Konto. Dann kommt im folgenden Shellskript "remotesupport.sh" anstelle der ermittelten IP-Adresse die Dyndns-URL zum Einsatz, sodass das Skript nicht jedesmal neu erstellt werden muss. Im Beispiel wird angenommen, dass das Dyndns-Konto "techniker.dyndns.org" zur Verfügung steht.
  2. Die Konfiguration des Routers des Technikers wird so geändert, dass dieser den Port 22 auf den Port 22 des Rechners des Technikers weiterleitet. Je nach Router kann diese Einstellung "Portforwarding", "Exposed Host" oder "Virtual Server" heissen.
  3. Konfiguration des Rechners des Technikers.
    1. Installation eines SSH-Servers, am besten Openssh.
    2. Benutzerkonto zur Verwendung des Reverse-SSH-Tunnels.
    3. Installation eines VNC-Clients.
    4. Konfiguration des SSH-Servers, der Benutzer anhand eines Public Keys identifizieren können muss.
      1. Anpassung der Datei "/etc/ssh/sshd_config", wo die Variable "PubkeyAuthentication yes" gesetzt werden muss.
      2. Neustart des SSH-Servers mittels "sudo etc/init.d/ssh restart".
    5. Erstellen des Benutzers "remotesupport" mittels "sudo useradd -m -d /home/remotesupport -s /bin/false remotesupport".
    6. Erstellen des Passworts für Benutzer "remotesupport" mittels "sudo passwd -l remotesupport".
    7. Erzeugen eines Schlüsselpaars für den Zugang durch Aufruf von "ssh-keygen" als Benutzer "remotesupport".
    8. Damit der SSH-Server den Schlüssel erkennt, wird als Benutzer "remotesupport" der Befehl "cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys" ausgeführt.
  4. Konfiguration des Rechners des Benutzers; hier werden nur temporär einige Parameter umgestellt. Das Umstellen könnte auch der Benutzere selbst erledigen, dabei können sich jedoch Fehler einschleichen, weswegen ein Shellskript dafür besser geeignet ist. Das Shellskript "remotesupport.sh" sorgt für den Aufbau des SSH-Tunnels. Dazu muss sich der SSH-Client ohne Passwort und ohne weiteres Zutun am Rechner des Technikers anmelden können, um einen Reverse-SSH-Tunnel zu öffnen.
    1. Der Befehl für den Reverse-SSH-Tunnel lautet wie folgt. Mit dem Schalter "-R" bittet der SSH-Client dabei beim SSH-Server um eine Weiterleitung. Der SSH-Server lauscht dann auf Port 10823 und leitet alle Daten, welche der SSH-Client dorthin schreibt, durch den SSH-Tunnel zum Port 5900 des Rechners des Benutzers weiter - damit gelangen später die Anfragen vom VNC-Client des Technikers an den VNC-Server des Benutzers. Der zweite Schalter "-R" baut zusätzlich einen zweiten SSH-Tunnel auf, welcher den Port 10285 auf den allenfalls vorhandenen SSH-Server (Port 22) des Rechners des Benutzers weiterleitet.
      $ ssh -i $PREFIX/privatekey -N remotesupport@techniker.dyndns.org -R 10823:localhost:5900 -R 10285:localhost:22
    2. Damit der Rechner des Technikers erkannt wird, wird der Hostkey des Rechners des Technikers in die Datei "~/.ssh/known_hosts" eingefügt. Mit dem Befehl "ssh-keyscan" erfolgt das auf einfache Weise (siehe das untenstehende Shellskript "remotesupport.sh").
    3. Der passende private Schlüssel wird ebenfalls auf dem Rechner des Benutzers abgelegt - das Shellskript "remotesupport.sh" wird ihn also gleich mitliefern.

Der erste Teil des bereits erwähnten Shellskripts "remotesupport.sh" sieht wie folgt aus:

#!/bin/bash
# Arbeitsverzeichnis zum Ablegen temporärer Daten.
PREFIX=/tmp/remotesupport
mkdir $PREFIX

# SSH-Verzeichnis erstellen.
if [ ! -f ~/.ssh/known_hosts ]; then
  mkdir ~/.ssh
  chmod 0700 ~/.ssh
fi

# Sicherung der Datei "known_hosts" zum späteren Wiederherstellen.
cp ~/.ssh/known_hosts $PREFIX/known_hosts

# Serverschlüssel kopieren.
ssh-keyscan -t dsa techniker.dyndns.org >> ~/.ssh/known_hosts
ssh-keyscan -t rsa techniker.dyndns.org >> ~/.ssh/known_hosts

# Privaten Schlüssel aus dem Skript schreiben.
# Alles bis zwischen den EOFs landet in der Ausgabedatei.
cat > $PREFIX/privatekey << EOF
-----BEGIN RSA PRIVATE KEY-----
...
-----END RSA PRIVATE KEY-----
EOF

# Zugriffsrechte richtig setzen.
chmod 0600 $PREFIX/privatekey

# Öffnen der SSH-Verbindung.
ssh -i $PREFIX/privatekey -N remotesupport@techniker.dyndns.org \
  -R 10823:localhost:5900 -R 10285:localhost:22 &

Im nächsten Abschnitt des Skripts "remotesupport.sh" wird der VNC-Server gestartet, damit der Techniker wirklich Zugriff auf die Arbeitsoberfläche des Benutzers erhält. Sowohl Gnome wie KDE liefern standardmässig einen VNC-Server mit, dieser ist allerdings weder konfiguriert noch aktiviert. Das Skript prüft also, welches der beiden Programme Vino (Gnome) oder KRFB (KDE) sich auf dem Rechner des Benutzers befindet:

ISTGNOME=$(which vino-preferences | wc -l)
ISTKDE=$(which krfb | wc -l)

# Gnome-Arbeitsoberfläche
if [ $ISTGNOME -eq 1 ]; then
  # Aktuelle Konfiguration sichern
  gconftool-2 --dump /desktop/gnome/remote_access > $PREFIX/vino_set
  # Neue Konfiguration erstellen
  gconftool-2 -s -t bool /desktop/gnome/remote_access/enabled true
  gconftool-2 -s -t bool /desktop/gnome/remote_access/local_only false
  gconftool-2 -s -t bool /desktop/gnome/remote_access/prompt_enabled false
  gconftool-2 -s -t bool /desktop/gnome/remote_access/view_only false
fi

# KDE-Arbeitsoberfläche
if [[ $HAVEVINO -eq 0 && $HAVEKRFB -eq 1 ]]; then
  # Aktuelle Konfiguration sichern
  cp ~/.kde/share/config/krfbrc $PREFIX/krfbrc_set
  # Neue Konfiguration erstellen
  cat > ~/.kde/share/config/krfbrc << EOF
allowDesktopControl=true
allowUninvited=true
confirmUninvitedConnection=false
disableBackground=true
disableXShm=false
enableSLP=false
preferredPort=5900
uninvitedPasswordCrypted=

[invitations]
invitation_num=0
EOF
  # KRFB muss einmal kurz gestartet werden, damit die Konfiguration
  # übernommen wird. Der Benutzer sieht dabei ein kleines Fenster, das sich
  # nach einer Sekunde wieder schliesst.
  krfb &
  sleep 1
  killall krfb
fi

Mit dem Skript "remotesupport.sh" wird also eine SSH-Verbindung hergestellt und ein VNC-Server auf dem Rechner des Benutzers gestartet. Der Techniker kann sich danach mit seinem VNC-Client auf den Socket "localhost:10283" verbinden und sieht die Arbeitsoberfläche des Benutzers.

Der Ordnung halber wird das Skript "remotesupport.sh" noch etwas erweitert, damit es nach Schliessen des SSH-Tunnels aufräumt. Dabei wird die Prozessliste nach dem Tunnelprozess durchsucht. Im Erfolgsfall wartet das Skript drei Sekunden und sucht erneut. Wird der Tunnelprozess nicht gefunden, so wird die Schleife beendet und das Skript läuft weiter. Anschliessend folgen noch einige Aufräumarbeiten.

SSHRUNNING=$(ps ax | \
  grep 'ssh -i $PREFIX/privatekey -N remotesupport@techniker.dyndns.org -R 10823:localhost:5900 -R 10285:localhost:22' | \
  grep -v grep | wc -l)
while [ $SSHRUNNING -gt 0 ]
  do
  SSHRUNNING=$(ps ax | \
    grep 'ssh -i $PREFIX/privatekey -N remotesupport@techniker.dyndns.org -R 10823:localhost:5900 -R 10285:localhost:22' | \
    grep -v grep | wc -l)
  sleep 3
  done

# Datei "known_hosts" wiederherstellen.
mv $PREFIX/known_hosts ~/.ssh/known_hosts

# VNC-Konfiguration wiederherstellen.
if [ $ISTGNOME -eq 1 ]; then
  gconftool-2 --load $PREFIX/vino_set
fi
if [[ $ISTGNOME -eq 0 && $ISTKDE -eq 1 ]]; then
  mv $PREFIX/krfbrc_set ~/.kde/share/config/krfbrc
  krfb &
  sleep 1
  killall krfb
fi

# Löschen des temporären Verzeichnisses.
rm -rf $PREFIX

Braucht nun jemand die Unterstützung des Technikers, so schickt dieser dem Benutzer einfach die Datei "remotesupport.sh". Der Benutzer braucht die Datei bloss ausführbar zu machen und anschliessend auszuführen.

Der Techniker sollte den Benutzer "remotesupport" nach getaner Arbeit auf seinem Rechner wieder sperren und das Portforwarding abschalten, damit der Rechner nicht mehr von aussen erreichbar ist.

Weblinks

Herausgeber Sprache Webseitentitel Anmerkungen
Wikipedia ger Fernwartungwbm Enzyklopädischer Artikel