Freebsd 5.3 Release X11 über ssh

E

El Jarczo

Active Member
Hi,
ich wollte X11 Fenster von einem FreeBSD Server (5.3 Release) über ssh auf einem
anderen Rechner darstellen lassen.
Vor ein paar Jahren ging sowas noch indem man auf dem Server
X11Forwarding = yes in die /etc/ssh/sshd_config tat und am Client ssh -X -C <ip_des_servers> machte.
Wenn ich das mache, bei gestartetem XServer auf dem Client sagt mir
xterm:
Can't op Display

Hab ich irgendwas vergessen??
Btw. XFree86 läuft natürlich.

MfG Christian
 
und da sehe ich plötzlich parallelen... :(
siehe mein aktueller post... (mist, den hat die suche mit forwarding net gefunden :( )

also sorry fürs doppelpost & hoffe auf kläääärung ;)
 
hmmm...
1. nein Daniel Seuffert ;), wurd auch net böse aufgefasst... die klärung der problematik iss mir am wichtigsten

MrFixit... hmm... naja, soweit war ich schonmal...

hab mich via ssh mit #ssh -Y <host> connected - kein problem!
nun kommt immer noch die problematik mit dem :

Code: 
#xterm &

xterm Xt error: Can't open display:
und zwar immer wenns ins "X"en geht...
und fertig! :( also könnt das doch was mit dem display zu tun haben...
oder wie?!
 
Zuletzt bearbeitet:
Hm,
also, der Server läuft bei mir wie gesagt unter FreeBSD 5.3.
Der Client ist ein WinXP Rechner mit Cygwin X, als ssh client
habe ich mingw's openssh, cygwin's openssh und Putty versucht.
Die logs sagen folgendes (ssh -v -X)

debug1: channel 0: new [client-session]
debug1: channel_new: 0
debug1: send channel open 0
debug1: Entering interactive session.
debug1: client_init id 0 arg 0
debug1: Requesting X11 forwarding with authentication spoofing.
debug1: channel request 0: shell
debug1: channel 0: open confirm rwindow 0 rmax 32768

wenn ich nun Xterm starten möchte:

chrjar@seppel:/home/chrjar>xterm
xterm Xt error: Can't open display: localhost:10.0

Ich glaube das es am Server liegt, da der Versuch mit einem Linux Rechner als Client das selbe ergebnis brachte.

Btw. ich hatte das mit Windows 2000 als Client und FreeBSD 4 als Server schon laufen.

Liegt es womöglich an den X.org Servern in 5.3-Release??


MfG, Christian
 
Ich glaube du wuerfelst SSH und X Server/Client ein wenig durcheinandern.

WAS ist der SSH-Server?

WAS ist der SSH-Client? Ist auf dem SSH-Client der X-Server korrekt eingerichtet?
 
MrFixit schrieb:
Ich glaube du wuerfelst SSH und X Server/Client ein wenig durcheinandern.Ist auf dem SSH-Client der X-Server korrekt eingerichtet?
Zum Vergrößern anklicken....

wo wir wieder bei der frage wären, welche voraussetzungen/configurationen ich auf beiden seiten vorzunehmen habe!
 
Also, der ssh Server läuft unter FreeBSD 5.3 Release.

Der ssh Client läuft unter Windows XP (Pro, SP2 - wegen CAD),
Cygwin XServer (X.Org 6.8 glaub ich), ist korrekt eingerichtet, Mit xdmcp und wdm läuft das auch.

Das ist aber Sicherheitstechnisch nicht optimal, zumal die X Programme auch von einem Linux Rechner (Suse 7 oder so) in einem anderen Subnetz genutzt werden sollen. Die beiden Subnetze (Netz A mit SSH Server und Windows Client, Netz B mit Linux Client) sind nur über einen SSH Tunnel server verbunden.

Deshalb wäre das X11 Forwarding von SSH die optimale Lösung.

MfG, Christian
 
Funktioniert das ganze mittels putty denn auf einem anderen Server? Ich glaube jedenfalls nicht, dass das hier der richtige Ort ist, um nach cygwin/xp-support zu fragen :D
 
du musst auf jedenfall das display setzten...
bei xterm -display ip:0
bei firefox --display=ip:0
in der regel steht das in der man oder --help etc
man kann auch global die variable setzen, damit hab ich mich aber noch nicht beschäftigt
unter linux macht man das mit export DISPLAY=IP:0

zur erklärung, das programm versucht seine ausgabe auf dem lokalen rechner zu bringen, weil du dir wahrscheinlich die mühe gespart hast auf dem server nen x zu installieren klappt das natürlich nicht.
deshalb die fehlermeldung.
das du das durch ssh getunnelt haben willst musst du ihm ja erstmal sagen und mit ssh -X weiß er auch kein stück mehr... außer das x forwarding erlaubt ist
sprich du musst sagen wohin, also ip angeben.



@mrfixit
wohin soll er denn sonst schreiben *g* wie man sowas macht ist betriebssystem spezifisch : )
und ob man nun die ausgabe des programms per cygwin auf windoof oder linux oder nen anderen freebsd rechner legt ist ja nu schnuppe ;)
 
Zuletzt bearbeitet:
AndreasMeyer schrieb:
Wieso benutzt Du nicht einfach VNC?
hmmm... joo... abba da müsst doch meine gegenstelle ebenfalls vnc installiert haben...
und da wo ich wurschtel, iss entweder hummingbird exceed drauf... oder cygwin...

oder gibts des als executable?! also "Nur" als zu entpackender ordner?!
Zum Vergrößern anklicken....
 
Hm, bin ich eigentlich der einzige, der das X11 forwarding von openssh nicht hinkriegt?

Zu den Empfehlungen mit vnc:

VNC ist aus meiner sicht keine Alternative, da zu unsicher und extra 2 Tunnel aufzumachen um eine Verschlüsselte VNC Verbindung in anderes Sub Netz zu kriegen ist mir auch zu aufwendig.

MfG,
Christian
 
du bist nicht allein :)

ich hab's vor einer weile auch versucht und bin leider gescheitert,
anscheinend ist es so trivial und für den großteil so verständlich,
dass es sich nicht erklären läßt oder so :confused:

wird mich auf jeden fall freuen wenn uns jemand helfen kann,
und wir endlich zu ssh getunneltem X kämen.

mfg dagnu
 
Funktioniert folgendes:

FreeBSD-Kiste
-----------------
Auf FreeBSD-Kiste sshd laufen lassen, /etc/ssh/sshd_config enthält folgende Zeile:
Code: 
#X11Forwarding yes
Dann mit #setenv kontrollieren ob:
Code: 
DISPLAY=:0.0
ist!

Windows-Kiste
-----------------
Dann auf der Windows-Kiste mit installiertem Cygwin folgendes eingeben:
Code: 
X -rootless &
export DISPLAY=localhost:0.0
ssh -C -X user@192.168.1.247 xclock

Bemerkungen
----------------
Ich habe es von einer FreeBSD 5.3- auf eine Solaris-Kiste über das Internet probiert und es funktioniert!
Quelle:
http://devcorner.schlenker-webdesign.de/cms.7.html
 
Zuletzt bearbeitet:
Eben das Funktioniert ja nicht.
Ich habe inzwischen alle logs, die damit zu tun haben könnten durchgesehen.
Obwohl ich inzwischen schon knapp 8 Jahre mit Unix Kisten zu tun habe, kann ich den Fehler nicht finden.

Langsam verzweifele ich.
Btw. xhost +<serverip>
und xterm -DISPLAY <serverip>:0
geht.

Hat denn niemand eine Idee woran das liegen könnte??

MfG,
Christian
 
Ich hatte vor kurzem auch mal Probleme mit ssh. Eigentlich aber, Probleme die man-Page zu lesen. Da gibt es einen neuen Parameter bzgl. X-Umleitung (-Y anstatt -X).

Ich weiß nicht ob dies auch Dein Problem ist, weil Deine Beschreibung etwas knapp ist.
 
El Jarczo schrieb:
Eben das Funktioniert ja nicht.
Ich habe inzwischen alle logs, die damit zu tun haben könnten durchgesehen.
Obwohl ich inzwischen schon knapp 8 Jahre mit Unix Kisten zu tun habe, kann ich den Fehler nicht finden.

Langsam verzweifele ich.
Btw. xhost +<serverip>
und xterm -DISPLAY <serverip>:0
geht.

Hat denn niemand eine Idee woran das liegen könnte??

MfG,
Christian
Zum Vergrößern anklicken....

Läuft dein X mit der option "-nolisten-tcp" ?

Wird häufig bei grafischen login Managern verwendet.

-MadMax
 
So, nach einem Festplattencrash auf dem BSD Rechner, hab ich mal OpenBSD installiert.
Dort hatte ich das selbe Problem. Durch zufall habe ich gerade die Lösung gefunden:

in der /etc/hosts gibt es einen Eintrag, der localhost eine ipv6 Adresse zu weist. Sobald der Auskommentiert wurde geht auch ssh -X serverip xterm wieder.

Das problem tritt scheinbar erst dann auf, wenn der Rechner, auf dem das xterm gestartet wird, mehr als eine Netzwerkkarte hat.
Ich denke mal das selbe Problem besteht auch bei FreeBSD.

MfG,
Christian
 
@MrFixit:
Das Problem war wohl, das ich hier kein ipv6 verwende.

Ich fand es auch seltsam. So wie ich das sehe, ist das problem, das port 22 an 127.0.0.1 != port 22 an der äquivalenten ipv6 Adresse ist. Da die Symptome gleich waren, dachte ich, das FreeBSD das selbe Problem hat. Es könnte aber auch an meiner Firewall liegen, ich nutze unter OpenBSD die selbe pf.conf ( die hatte ich glücklicher weise extern gesichert).
Naja, jedenfalls dachte ich, das das dagnu weiter helfen könnte.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben