Remote Desktop Clientseitig aufbauen

[sh0r]

Hallo!

Ich würde gerne jemanden etwas unter die Arme greifen und ihm ein paar Sachen per Remotedesktop (Debian zu Debian) zeigen. Hab ne Weile gesucht und verschiedene Möglichkeiten gefunden. Leider war da nicht genau das dabei, das ich möchte

Ich möchte gerne, dass derjenige, dem ich helfen soll, die Verbindung zu mir herstellt. Somit hätte ich das "Problem" dass er ein Loch in seine Firewall (und in meinen Geduldsfaden während ich ihm erkläre wie das geht ) bohren muss umgangen. Eigentlich würde ich der Einfachheit halber gerne das bei Gnome mitgelieferte Tool (System > Einstellungen > Entfernter Desktop) verwenden. Kann man das da irgendwie bewerkstelligen? Hab' gelesen, dass man sowas über ssh tunneln kann. Könnte derjenige zuerst eine Verbindung per ssh zu mir aufbauen und ich kann diese dann nutzen (geht so eine "bidirektionale" Verbindung überhaupt?)?

Gruß und Dankeschön,
shor

[Der-Nik]

Ich suche gerade nach dem gleichen . Ich habe gerade was von SSH -X gelesen, mal sehen ob es geht.

[sh0r]

Hallo Nik!

Soweit ich das verstanden habe, kannst Du mit der Option -X bei ssh lediglich auf dem Host, auf welchem Du eingeloggt bist, X-Programme (also Programme mit grafischer Oberfläche) starten und bei Dir sehen. Der User an dem anderen Rechner sieht davon nichts afaik. Man kann ihm also nichts zeigen. Und das Firewall-Problem löst es leider auch nicht...

Gruß
sh0r

[Baer]

hallo sh0r
wen du einen Remotedesktop-Server für Linux findest, melde das bitte, das ist etwa das einzige Microsoftprodukt welches ich wirklich vermisse.
(im Überigen sieht der enntfernte User nicht was du tust, mit Remotedesktop baust du eine eigene Session auf.)

Was Du suchst ist eher VNC.

Was funktionieren müsste (ungetestet) ist:
bei deinem Kollegen ausgeführt:

Code: Alles auswählen

  ssh -RN dein_port:sein_rechner:sein_port dein_rechner 

-R --> Port weiterleiten
-N --> Kein Befehl ausführen

Dass Baut einen Tunnel auf. Dieser bewirkt folgendes
Er baut eine ssh Verbindung zu "dein_rechner" auf. (ganz normal, via port 22)
Wenn die Verbindung steht, werden alle anfragen welche auf DEINEM_RECHNER auf dein_Port eingehen nach sein_rechner auf sein_port weitegleitet.
Wenn du jetzt also vncviewer localhost eingiebst wirt das auf sein_rechner weiter geleitet.
Vorausgesetzt ist natürlich dass bei ihm ein VNC-Server läuft, und die Ports die Richtigen sind (afaik 5900).

Schritt für Schritt heisst dass also:
Er Startet seinen VNC-Server und baut den Tunnel auf:

Code: Alles auswählen

 ssh -RN 5900:sein_rechner:5900 dein_rechner

Du Baust die VNC-Verbindung auf:

Code: Alles auswählen

vncviewer localhos

Und drinne solltest du sein.

Wenn meine Beschreibung unverständlich sein sollte, läge dass an der Späten Stunde und den Rahmenbedingungen.
Auf gutes gelingen und
Prost Urs

[uname]

Eine textbasierte (nur SSH) Lösung kann ich anbieten. Ich habe einige Jahre lang daran rumgeschraubt. Dafür ist sie auch hinter einem DSL-Router nutzbar und ermöglicht textbasierte SSH-Fernwartung im 4-Augen-Prinzip ohne Kenntnis von Passwörtern des Fernzuwartenden. Voraussetzungen sind SSH-Server beim Fernzuwartenden (mindestens localhost), SSH-Server und Anwendung "screen" auf dem eigenen Rechner. Die Voraussetzung des SSH-Servers beim Fernzuwartenden ist etwas komisch, sollte aber kein Problem sein. Durch die Beschränkung auf "localhost" entsteht kein Sicherheitsrisiko.

Vorbereitung auf eigenem System:

Installation Paket "screen", Anlegen Fernwartungs-Benutzer "restricted" mit Restricted-Shell z.B. /usr/local/bin/shell:

/usr/local/bin/shell:

Code: Alles auswählen

#!/bin/sh
if [ -z $STY ];   then                  
  /usr/bin/screen -xRR;                                                         
else                                                                            
  /usr/bin/screen -X hardstatus alwayslastline '[%H] %Lw%=%u %d.%m.%y %c '
  echo -n "ssh "                                                        
  read eingabe;                                                                 
  befehl="/usr/bin/ssh $eingabe";                                               
  $befehl;                                                                      
  read eingabe;                                                                 
fi

(Statusausgabe und das letzte read sind optional)

Durchführung der Fernwartung:

Die Person baut eine SSH-Verbindung auf (evtl. per Script, kann man ja vorher einrichten):

Code: Alles auswählen

ssh -R 2222:localhost:22 restricted@ssh-server-im-internet

Nun erscheint nur die Ausgabe "ssh " und ein Cursor. Gleichzeitig meldet man sich selbst auch an. Nun geht man mit:

Code: Alles auswählen

ssh user@localhost -p 2222

zurück auf den fernzuwartenden Rechner. Man kann nun mit zwei Personen genau sehen was passiert.

Anmerkung:
Die "known_hosts" vom Benutzer "restricted" können zu Warnungen führen. Die Datei /home/restricted/.ssh/known_hosts ist evtl. zu löschen. Ein Sicherheitsrisiko sollte nicht entstehen, da mit der Shell nur der Befehl "ssh" als eine Art SSH-Proxy genutzt werden kann. Das Passwort ist nicht so kritisch, alternativ kann man natürlich auch SSH-Keys einsetzen. Zur weiteren Automatisierung kann man sogar den SSH-Befehl noch vorgeben und somit den "Rückweg" automatisch aufrufen lassen.

[sh0r]

Hallo zusammen!

Vielen Dank für eure Antworten! Ich werde mich demnächst mal daran machen, das auszuprobieren. Im Moment fehlt mir hier gerade leider der zweite Rechner, um das erstmal für mich selbst zu testen, der sollte aber in ein paar Tagen wieder fit sein. Das mit dem SSH-Tunnel sieht vielversprechend aus, glaube das kommt dem was ich vor hatte am nähesten. Die Sache mit der Konsole ist klasse aber ich glaube wenn ich meinem "Patienten" zuviel Konsole verschreibe kriegt er ne Phobie...

@Baer: Bin mir nicht sicher, welche Art von Remotedesktopserver Du genau suchst - vielleicht sowas: http://www.nomachine.com ?

Schönes Wochenende,
sh0r

[Baer]

"Remote Dektop" ist der Produktenamen für die Fernzugriffsoftware aus dem Hause Microsoft, und für Unixoide gibt es nur clients, also kein Debian zu Debian.
Der Kommentar bezog sich nur darauf, dass du diesen Produktnamen als Synonym für Grafischen Fernzugriff verwendet hast.
Im Übrigen ist das, was du machen willst die Verbindung vom Server her auf zu bauen und eben nicht vom Client.
Server: Gerät / Software auf welche zugegriffen wird, (web- , ftp-, oder eben vnc-Server)
Client: Gerät / Software welches zugreift (webbrowser, ftpprogramm, vncviewer)

[sh0r]

Hallo Baer,

Ahso - nun gut, in dem Fall wird man wohl keinen Remote Desktop Server für Linux finden
Den Server/Client hab ich wohl vertauscht, da ich denjenigen, dem ich helfen wollte wohl automatisch als mein "Klient" angesehen habe

Danke für die Klarstellung!

Gruß,
sh0r

[sh0r]

Hallo Baer!

Inzwischen konnte ich Deinen Vorschlag ausprobieren! Kurzum: hat super geklappt, vielen Dank!
Ich habe das ganze noch "verbessert", indem ich dem Benutzer, den ich brauche, damit mein Schützling die SSH Verbindung zu meinem Rechner aufbauen kann stark in seinen Rechten eingeschränkt habe. Er soll ja schließlich nur einen Tunnel benutzen und keinen Account haben mit welchem er auf meinem Rechner arbeiten kann. Außerdem soll der Aufbau des Tunnels ohne Passworteingabe möglich sein bzw. soll diese nur einmal gemacht werden müssen.

Hierfür habe ich den sshd so konfiguriert, dass kein login per Passwort mehr möglich ist:

Code: Alles auswählen

PasswordAuthentication no
UsePAM no 

Anschließend habe ich für den Tunnel-Benutzer einen Schlüssel erstellt. Hierfür als Tunnel-Benutzer folgendes ausführen:

Code: Alles auswählen

ssh-keygen -t dsa

Der Tunnel-Benutzer muss danach natürlich den Schlüssel (id_dsa) per Mail o.ä. geschickt bekommen und man muss ihm die Passphrase mitteilen. Wenn er den Tunnel das erste mal aufbaut und diese eingibt wird sie im Gnome-Keyring gespeichert und die Eingabe ist fortan nicht mehr nötig.

Damit der Tunnel-Benutzer keine Kommandos per SSH absetzen kann wenn er den Tunnel aufgebaut ist, müssen die zulässigen Kommandos im authorized_keys File des Tunnel-Benutzers festgelegt werden. Dafür muss folgende Option im sshd gesetzt werden:

Code: Alles auswählen

PermitUserEnvironment yes

Danach muss folgendes im authorized_keys File (~/.ssh/authorized_keys) gesetzt werden:

Code: Alles auswählen

command="while :;do date;sleep 50;done" ssh-dss AAAAB3N...

Das Format ist hier wichtig! Vor dem Ausdruck ssh-dss muss ein Leerzeichen stehen!

Gruß,
sh0r

[Baer]

Cool das das so gut funktioniert!
danke für feedback

nur um der Paranoia genüge zu tun noch folgendes:
Mail ist, sofern nicht GPG/PGP verschlüsselt, sind unsicher. ich mach es jeweils umgekehrt. Zuerst die Schlüssel generieren, dann per ssh-copy-id übertragen, und dann, wenn Passwort login nicht erwünscht ist, pw login deaktivieren (Schlüssellogin funktioniert auch bei aktivem pw login).
So wird der Schlüssel verschlüsselt übertragen.
Wer richtig paranoid ist überträgt den Schlüssel per USB-Stick, dann sind auch man-in-the-middle attacken bei der ersten Verbindung verunmöglicht.
(kann auch verhindert werden wenn man die Finerprints vergleicht, und ist sowiso sehr unwahrscheinlich)

LG Urs

[sh0r]

Also erstellt bei Dir der Tunnel-Benutzer die Schlüssel und überträgt diesen per ssh-copy-id auf den Rechner, zu welchem der Tunnel erstellt werden soll?
Für das Benutzen des Schlüssels benötige ich doch die festgelegt Passphrase - die weiß der Mann in der Mitte ja nicht.
Oder stehe ich grad auf dem Schlauch?

Gruß,
sh0r

[Baer]

Die Schlüssel werden gleich erstellt wie bei dir, nur die Übertragung ist anders.

Du hast recht, die Passphrase wird gebraucht, und das man-in-the-middle Szenario ist sowieso sehr unwahrscheinlich.
Wer würde sich schon diesen Aufwand machen, um im besten Fall an die Informationen eines X-beliebigen Menschen zu kommen, da sind Phishing, Trojaner usw. effizienter.

nur um der Paranoia genüge zu tun noch folgendes:

ssh ist ein echtes Hochsicherheits-Tool, deswegen habe ich gefunden, diese Einwände gehören erwähnt. Ich bin nicht der Meinung, dein Vorgehen in dieser Situation sei über die Massen fahrlässig, aber streng genommen gehört das sichere Übertragen der Schlüssel zum Sicherheitskonzept. Nur als Ergänzung gedacht.
LG Urs

[sh0r]

Also wenn ich als Helfender die Schlüssel erstelle, benutze ich dann ssh-copy-id um den Schlüssel auf den Rechner vom demjenigen zu übertragen, dem ich helfen will?
Kannst Du das mal genauer ausführen?

[Baer]

mach doch mal

Code: Alles auswählen

man ssh-copy-id

Dort ist das schön beschrieben.

der pub-key muss irgendwie übertragen werden, ssh-copy-id ist einfach ein tool welches das tut, mit scp, gpg verschlüsseltem mail, oder sonstwie verschlüsselt ist genau gleich gut, braucht nur noch ein bisschen mehr Handarbeit.

In deinem fall ist das nicht ganz so praktisch weil der Schlüsselempfänger nicht direkt per ssh erreichbar ist.

[sh0r]

Hmm. Ich glaube wir reden aneinander vorbei oder Du hast den öffentlichen mit dem privaten Schlüssel verwechselt.

Ich hab' sogar nochmal in die man page reingeschaut! ssh-copy-id wird verwendet um den öffentlichen Schlüssel auf den Server zu kopieren. Derjenige der den Tunnel aufbauen möchte braucht jedoch den privaten Schlüssel (den öffentlichen habe ich ja schon auf meinem Rechner, da ich den zusammen mit dem privaten generiert habe) und den kann man nicht mit ssh-copy-id übertragen.

Ich denke mal die sicherste vorgehensweise wäre die:
Derjenige, dem ich helfen will, erstellt mit ssh-keygen sein Schlüsselpaar und installiert selbst seinen öffentlichen Schlüssel per ssh-copy-id auf meinem Rechner. In diesem Fall kann erst nach dieser Installation der login per Passwort verboten werden.

In meinem Fall möchte ich meinem Gegenüber das aber nicht zumuten.
Also habe ich den Schlüssel selbst erstellt (in diesem Fall kann ich auf das Verwenden von ssh-copy-id verzichten). Den privaten Schlüssel muss ich meinem Gegenüber irgendwie zukommen lassen. Hier hast du natürlich völlig recht - der Schlüssel sollte auf einem sicheren Kanal versendet werden.

Hoffe wir stimmen überein Irgendwie bin ich verwirrt

[Baer]

OK, soweit Stimmen wir überein, abgesehen davon das es ein Sakrileg ist, wen ein privater Schlüssel den Rechner verlässt auf welchem er generiert wurde .
Ist sozusagen ein Kapitalverbrechen .

LG Urs

[sh0r]

Wunderbar
Sobald ich den Rechner meines Schützlings unter Kontrolle habe, kann ich ja selber bei ihm den Schlüssel generieren und per ssh-copy-id zu mir kopieren

Danke nochmal für Deine Hilfe!

Gute Nacht