grafische Ausgabe vom server nach zu Hause - oppenvpn

[fakespace]

Moin

ich moechte gern auf einen Linux server zugreifen. Klappt auch wunderbar, per SSH. Nun moechte ich aber genr auch grafische Sachen auf dem server nutzen. Das hat folgenden Grund: 2 Bekannte von mir moechten auf dem server arbeiten. Allerdings eben mit einer grafsichen Oberflaeche. Nun wollte ich fragen, ob das per openvpn moeglich ist.

Wenn ich auf dem server, und die beiden auf ihren clienten jeweils openvpn installiere und starte, haben die ja noch keine grafische Operflaeche, oder ?


Wenn einer ne andere, gute Idee hat, bin fuer alles offen



Danke auf jeden Fall schonmal fuer Eure Hilfe

[eagle]

Wozu willst du denn gleich OpenVPN installieren. Wenn du schon ssh nutzt, dann reicht es doch das X Forwarding mit ssh -X user@recher. Das X Forwarding (X11Forwarding yes) muss aber auch auf dem ssh Server in der Datei /etc/ssh/sshd_config eingeschaltet werden.

eagle

[fakespace]

Ok, hoert sich sehr simpel an, aber wenn ich mich per

Code: Alles auswählen

ssh -X user@host kdeedit

bekomm ich als Fehler:

kedit: cannot connect to X server

[gms]

überprüfe einmal die /etc/ssh/sshd_config am Server, ob dort X11Forwarding eingeschaltet ist

und nacher "/etc/init.d/ssh reload" aufrufen

[edit]
Der X-Server muß am Client laufen, der X-Server am Server ist nicht relevant
[/edit]

[eagle]

@fakespace du musst einfach das gewüschte X Programm wie zum Beispiel xterm in der ssh Konsole aufrufen und es sollte dann auf deinem lokalen Bildschirm erscheinen.

Ein startx macht überhaupt keinen Sinn.

eagle

[fakespace]

Ja, das mit dem X-server hab ich verrafft . . .



Also, nochmal:

Ich hab mittlerweile ein vpn laufen. Mein Notebook is als 10.0.0.1 erreichbar.
Ich connecte zum server, logge mich mit "ssh -X user@host" ein
Dann mache ich ein "export DISPLAY=10.0.0.1:0.0"
Dann versuche ich kedit zu starten, bekomme aber den Fehler

kedit: cannot connect to X server 10.0.0.1:0.0

In der /etc/ssh/ssh_config hab ich den Eintrag

Code: Alles auswählen

ForwardX11 yes

auch /etc/init.d/ssh reload hab ich ausgefuehrt

[gms]

wenn du dich mit "ssh -X user@host" sollte eigentlich die DISPLAY Variable automatisch gesetzt werden:

Beispiel:

Code: Alles auswählen

gms@gms1:~$ ssh gms2
Linux gms2 2.6.10-dk-1 #1 Wed Feb 16 16:06:38 CET 2005 i686 GNU/Linux
Last login: Sat Feb 26 21:05:05 2005 from gms1
gms@gms2:~$ echo $DISPLAY
localhost:10.0
gms@gms2:~$

Sie wird immer auf "localhost" gesetzt, von dort gehts dann per SSH-Tunnel zum wirklichen X-Server am Client

[fakespace]

wenn ich mich zum server verbinde (ssh -X user@host) und dann ein

Code: Alles auswählen

echo $DISPLAY

mache, bekomm ich ne leere Zeile. Wenn ich dann das Diplay exporte und mir die Variable nochmal anzeigen lasse kommt

10.0.0.1:0.0

sollte also richtig sein. Allerdings bekomme ich beim Aufruf eines Programms trotzdem den Fehler, dass zum X-Server nicht connected werden kann

[gms]

wenn 10.0.0.1 dein Server ist, ist 10.0.0.1:0.0 vermutlich der X-Server der auf dem Server lauft.

rufe einmal auf deinem Client "xhost +10.0.0.1" auf oder/und verwende einmal
"ssh -XA user@host kedit"

[fakespace]

Nein, 10.0.0.1 ist mein notebook, 10.0.0.2 ist der server, deshlab ja ein

export DISPLAY=10.0.0.1:0.0

damit er die Ausgabe an mein Notebook schickt. Hab es auch schon mit der IP(also 84.128....)versucht, die ich im Moment hab, das geht auch nich

[gms]

willst du jetzt ssh mit X11Forwarding verwenden oder ist dir die Verschlüsselung wurscht ?
Im ersten Fall muß sich der X-Client zu localhost (am Server) connecten, damit ssh die Verschlüsselung zu deinem Notebook übernehmen kann.
Im zweiten Fall mußt du dich nur über irgendein Terminal connecten, die DISPLAY Variable auf 10.0.0.1:0.0 setzen, vorher am Notebook xhosts +10.0.0.2 aufrufen und es sollte funktionieren

[fakespace]

Verschluesselung waere ganz nett, aber vor allem soll es funktionieren.

Im ersten Fall muß sich der X-Client zu localhost (am Server) connecten, damit ssh die Verschlüsselung zu deinem Notebook übernehmen kan

wuerde ja bedeuten, dass auf meinem server ein X-server laufen muesste, oder wie meinst das ?



Den 2. Fall bin ich am versuchen, der geht allerdings nicht. Wie shcon gesagt, X11 Forwarding steht auf yes, die Display Variable aufm dem server hab ich auf 10.0.0.1 (meine IP im vpn) gesetzt, hab sie auch schon auf meine externe IP gesetzt, dann versucht, kedit zu starten und jedesmal kommt der Fehler, dass er zum X-Server nicht connecten kann

[gms]

Im ersten Fall muß sich der X-Client zu localhost (am Server) connecten, damit ssh die Verschlüsselung zu deinem Notebook übernehmen kan

wuerde ja bedeuten, dass auf meinem server ein X-server laufen muesste, oder wie meinst das ?

ssh setzt die DISPLAY Variable, der X-Client connected sich auf diesen Port, ssh forwarded diesen Port vom Server zum tatsächlichem X-Server am Client

[gms]

(meine IP im vpn)

Warum VPN das X11 Forwarding wurde dir doch als alternative zu VPN angeboten ?

[fakespace]

Das vpn hab ich zum probieren gebaut. Mit der oeffentlichen IP hat es nicht funktioniert, tut es auch immer noch nicht. Und wenn ich "einacfh nur" das X11 forwarde, habe ich ja keine Verschluesselung. Wenni ch es aber auf eine IP im vpn forwarde, sollte ja eine Verschluesselung da sein, weil das vpn ja verschluesselt ist, oder taeusche ich mich da ?
Koennte es nicht am -nolisten eintrag in der Xservers liegen ? Wenn ich das allerdings rausnehme, startet mein kdm nicht mehr

ssh setzt die DISPLAY Variable, der X-Client connected sich auf diesen Port, ssh forwarded diesen Port vom Server zum tatsächlichem X-Server am Clien

und wie darf ich das verstehen ? Ich hab ja schon mehrmals gesagt, wie ich vorgegangen bin, allerdings weiss ich nicht, was ich noch anders versuchen soll

[gms]

Koennte es nicht am -nolisten eintrag in der Xservers liegen ?

nein, du verwendest ja X11Forwarding, daher aus der Sicht des X-Servers connected sich ja ein lokaler Client.

Bei mir funktioniert es mit "nolisten tcp"

Code: Alles auswählen

root      9449  9247  2 14:36 ?        00:11:05 /usr/X11R6/bin/X :0 -audit 0 -auth /var/lib/gdm/:0.Xauth -nolisten tcp vt7

Ich habe auch noch nie mehr dazu benötigt, als die Änderung in der /etc/ssh/sshd_config und "ssh -X". danach wird bei mir die DISPLAY Variable automatisch und vorallem richtig gesetzt und alles funktioniert.

Es gibt dazu aber einen ähnlichen Fall:
http://www.debianforum.de/forum/viewtop ... highlight=

[fakespace]

Jo, den hab ich auch gelesen


Hab es nun mal nach


http://www.jfranken.de/homepages/johann ... h2.de.html

versucht, eigentlich das selbe, was ich schon seit ... keine Ahnung wie lange versuch Aber es geht einfach nicht, und ich weiss nicht, warum


Was ich allerdings auch noch "komisch" finde:

oft heisst es, man muss in der ssh_config

Code: Alles auswählen

X11Forwarding yes

eintragen, das fuehrt allerdings zu nem fehler, waehrend

Code: Alles auswählen

ForwardX11 yes

keinen bringt. Das aber nur nebenher, wie der befehl im einzelnen heisst sollte ja egal sein, solnage er das selbe macht

[gms]

in der /etc/ssh/sshd_config (=Server Konfiguration) heißt es X11Forwarding in der /etc/ssh/ssh_config (=Client Konfiguration) bzw in der ~/.ssh/config heißt es "ForwardX11"

[fakespace]

Also eine ~/.ssh/config hab ich nicht.


Und auf dem server bringt ein

Code: Alles auswählen

X11Forwarding yes

eine Fehlermeldung

/etc/ssh/ssh_config: line 37: Bad configuration option: X11Forwarding

Vielleicht noch zu erwaehnen: server is woody, mit
OpenSSH_3.4p1 Debian 1:3.4p1-1.woody.3, SSH protocols 1.5/2.0, OpenSSL 0x0090603f


Notebook is sarge mit
OpenSSH_3.8.1p1 Debian-8.sarge.4, OpenSSL 0.9.7e 25 Oct 2004

[gms]

/etc/ssh/ssh_config: line 37: Bad configuration option: X11Forwarding

/etc/ssh/sshd_config verwendet X11Forwarding
/etc/ssh/ssh_config verwendet ForwardX11

ich habe allerdings bei beiden die gleiche Version:

Code: Alles auswählen

Server: OpenSSH_3.8.1p1 Debian-8.sarge.4, OpenSSL 0.9.7e 25 Oct 2004
Client: OpenSSH_3.8.1p1 Debian-8.sarge.4, OpenSSL 0.9.7e 25 Oct 2004

[gms]

hast du jetzt den Unterschied gesehen, am Server ist die Datei
/etc/ssh/sshd_config zuständig und nicht die
/etc/ssh/ssh_config