Keine externe X-Anwendung auf lokalen Desktop mit Fritzbox als Router unter OpenSuSE 12.1
Hallo Liste, ich kann von einer externen Maschine keine X-Fenster auf meinen lokalen Desktop anzeigen. Was habe ich gemacht: 1) xhost + access control disabled, clients can connect from any host 2) ssh -X user@remote.machine.de 3) Linux remote:: /home/user>xterm . . . Es popt kein xterm auf. Dann habe ich via /sbin/ifconfig ermittelt: inet Adresse:192.168.178.22 Bcast:192.168.178.255 Maske:255.255.255.0 Darauf auf dem remote host: Linux remote:: /home/user>export DISPLAY=192.168.178.22:0 Linux remote:: /home/user>xterm Nichts passiert.... Meine Fritzbox ist wie folgt konfiguriert: Name IP-Adresse MAC-Adresse linux-3gwi 192.168.178.22 54:04:A6:A4:6C:E4 Also die 192.168.178.22 im export war richtig. Trotzdem vermute ich, dass die Fritzbox als Router der Grund dafür ist, dass ich das xterm nicht auf meinem lokalen Desktop sehe. Welche / wer weiß Rat? Liebe Grüße Alexander Trotzdem kann ich von extern export DISPLAY=192.168.178.255:0 also ein export für die Bcast-Adresse -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
On Sun, Mar 25, 2012 at 12:22:11PM +0200, alibeck wrote:
Hallo Liste,
ich kann von einer externen Maschine keine X-Fenster auf meinen lokalen Desktop anzeigen. Was habe ich gemacht:
1) xhost + access control disabled, clients can connect from any host
Bei ssh -X nicht noetig und zusaetzlich unsicher.
2)
ssh -X user@remote.machine.de
3)
Linux remote:: /home/user>xterm . . . Es popt kein xterm auf.
Gibt es Fehler? Bei ssh -X user@remote.machine.de wird ein "DISPLAY" gesetzt, was dann ueber das ssh zurueck getunnelt wird. Sprich in Schritt 2 ein "echo $DISPLAY" was dann da gesetzt sein sollte. ciao, Marcus -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
On Sunday 25 March 2012 13:18:07 Marcus Meissner wrote:
On Sun, Mar 25, 2012 at 12:22:11PM +0200, alibeck wrote:
Hallo Liste,
ich kann von einer externen Maschine keine X-Fenster auf meinen lokalen Desktop anzeigen. Was habe ich gemacht:
1) xhost + access control disabled, clients can connect from any host
Bei ssh -X nicht noetig und zusaetzlich unsicher.
2)
ssh -X user@remote.machine.de
3)
Linux remote:: /home/user>xterm . . . Es popt kein xterm auf.
Gibt es Fehler?
Nicht einen Einzigen :-(
Bei ssh -X user@remote.machine.de wird ein "DISPLAY" gesetzt, was dann ueber das ssh zurueck getunnelt wird. Sprich in Schritt 2 ein "echo $DISPLAY" was dann da gesetzt sein sollte.
Werde ich erst heute Abend mal testen können. Grundsätzlich sollte es jedoch - wenn ich Dich richtig verstanden habe, keine Probleme durch Zwischenschalten eines Routers geben? Liebe Grüße Alexander -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 25.03.2012 12:22, schrieb alibeck:
inet Adresse:192.168.178.22 Bcast:192.168.178.255 Maske:255.255.255.0
Darauf auf dem remote host:
Linux remote:: /home/user>export DISPLAY=192.168.178.22:0 Linux remote:: /home/user>xterm
Mal zum Verständnis: Was heißt bei Dir in dem Fall "Remote"? Steht die Kiste, deren Display Du exportieren willst im Internet? Grüße Ralf -- Antworten bitte nur in die Mailingliste! PMs bitte an: listpm (@) arndt-de (.) eu -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
On Monday 26 March 2012 09:19:49 Ralf Arndt wrote:
Am 25.03.2012 12:22, schrieb alibeck:
inet Adresse:192.168.178.22 Bcast:192.168.178.255 Maske:255.255.255.0
Darauf auf dem remote host:
Linux remote:: /home/user>export DISPLAY=192.168.178.22:0 Linux remote:: /home/user>xterm
Mal zum Verständnis: Was heißt bei Dir in dem Fall "Remote"? Steht die Kiste, deren Display Du exportieren willst im Internet?
Nein, das sind Linux-Server bei uns im Institut, auf denen ein paar X- Anwendungen laufen die ich auch mal zu Hause anzeigen lassen möchte. Mit einem DSL-Modem war das kein Problem, jetzt aber mit der Fitzbox... Außerdem habe ich zeitgieich von OpenSuSE 10.2 auf OpenSuSE 12.1 umgestellt. Unter 10.2 hatte ich den Router nicht verwendet. Liebe Grüße Alexander -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 26.03.2012 13:23, schrieb Alexander Beck-Ratzka:
On Monday 26 March 2012 09:19:49 Ralf Arndt wrote:
Am 25.03.2012 12:22, schrieb alibeck:
inet Adresse:192.168.178.22 Bcast:192.168.178.255 Maske:255.255.255.0
Darauf auf dem remote host:
Linux remote:: /home/user>export DISPLAY=192.168.178.22:0 Linux remote:: /home/user>xterm
Mal zum Verständnis: Was heißt bei Dir in dem Fall "Remote"? Steht die Kiste, deren Display Du exportieren willst im Internet?
Nein, das sind Linux-Server bei uns im Institut, auf denen ein paar X- Anwendungen laufen die ich auch mal zu Hause anzeigen lassen möchte. Mit einem DSL-Modem war das kein Problem, jetzt aber mit der Fitzbox...
Außerdem habe ich zeitgieich von OpenSuSE 10.2 auf OpenSuSE 12.1 umgestellt. Unter 10.2 hatte ich den Router nicht verwendet.
Wie verbindest Du Dich denn von zuhause mit dem Institut? VPN Tunnel? Hintergrund meiner Frage: Du gibst auf dem Rechner im Institut eine private IP Adresse (192.168.x.x) an. Diese sind privaten Netzen vorbehalten und dürfen nicht ins Internet geroutet werden. Weiß der Linux-Server im Institut denn, wie er über diese Adresse an Deinen Rechner bei Dir zuhause kommt? Grüße Ralf -- Antworten bitte nur in die Mailingliste! PMs bitte an: listpm (@) arndt-de (.) eu -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 3/26/2012 1:37 PM, schrieb Ralf Arndt:
Am 26.03.2012 13:23, schrieb Alexander Beck-Ratzka:
On Monday 26 March 2012 09:19:49 Ralf Arndt wrote:
Am 25.03.2012 12:22, schrieb alibeck:
inet Adresse:192.168.178.22 Bcast:192.168.178.255 Maske:255.255.255.0
Darauf auf dem remote host:
Linux remote:: /home/user>export DISPLAY=192.168.178.22:0 Linux remote:: /home/user>xterm
Mal zum Verständnis: Was heißt bei Dir in dem Fall "Remote"? Steht die Kiste, deren Display Du exportieren willst im Internet?
Nein, das sind Linux-Server bei uns im Institut, auf denen ein paar X- Anwendungen laufen die ich auch mal zu Hause anzeigen lassen möchte. Mit einem DSL-Modem war das kein Problem, jetzt aber mit der Fitzbox...
Außerdem habe ich zeitgieich von OpenSuSE 10.2 auf OpenSuSE 12.1 umgestellt. Unter 10.2 hatte ich den Router nicht verwendet.
Wie verbindest Du Dich denn von zuhause mit dem Institut? VPN Tunnel?
Hintergrund meiner Frage: Du gibst auf dem Rechner im Institut eine private IP Adresse (192.168.x.x) an. Diese sind privaten Netzen vorbehalten und dürfen nicht ins Internet geroutet werden. Weiß der Linux-Server im Institut denn, wie er über diese Adresse an Deinen Rechner bei Dir zuhause kommt?
Teils / teils. Ich gehe mti aber auch ohen VPN rein. Eine Maschine ist fei zugänglich, die anderen nur über vpn. Eine X-Anwendung bekomme ich in beiden Fällen nicht angezeigt. Was braucht ihr noch an Infos? Den Punkt mit dem VPN routen werde ich gleich mal bei unserem IT-Support klären. Liebe Grüße Alexander -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 26.03.2012 13:43, schrieb alexander.beck-ratzka:
Am 3/26/2012 1:37 PM, schrieb Ralf Arndt:
Wie verbindest Du Dich denn von zuhause mit dem Institut? VPN Tunnel?
Hintergrund meiner Frage: Du gibst auf dem Rechner im Institut eine private IP Adresse (192.168.x.x) an. Diese sind privaten Netzen vorbehalten und dürfen nicht ins Internet geroutet werden. Weiß der Linux-Server im Institut denn, wie er über diese Adresse an Deinen Rechner bei Dir zuhause kommt?
Teils / teils. Ich gehe mti aber auch ohen VPN rein. Eine Maschine ist fei zugänglich, die anderen nur über vpn. Eine X-Anwendung bekomme ich in beiden Fällen nicht angezeigt.
Falls Du Dich von zuhause über einen VPN Tunnel mit dem Institut verbindest, sollten Dir andere helfen. Ich habe da nur geringe Kenntnisse, die auch nur theoretischer Natur sind. Meines Wissens müsste jedenfalls Deine Netzwerkadresse zuhause aus dem Netzwerk des Instituts sein und der Weg vom Institut "nach Hause" muss bekannt sein. Falls Du Dich direkt in das Netz des Instituts verbindest (geht das überhaupt in der Postmodem Zeit?) gilt selbiges wie oben für Deine heimatliche Netzwerkadresse. Dritter Fall: Du verbindest Dich über einen Provider mit dem Internet und baust eine normale TCP/IP Verbindung mit dem Institut auf. Dann musst Du vom Institut aus die externe IP Adresse Deiner Fritzbox verwenden (ggf. höherer Port) und auf der Fritzbox eine Port Weiterleitung zu Deinem internen Rechner definieren. Grüße Ralf -- Antworten bitte nur in die Mailingliste! PMs bitte an: listpm (@) arndt-de (.) eu -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 3/26/2012 2:20 PM, schrieb Ralf Arndt:
Am 26.03.2012 13:43, schrieb alexander.beck-ratzka:
Am 3/26/2012 1:37 PM, schrieb Ralf Arndt:
Wie verbindest Du Dich denn von zuhause mit dem Institut? VPN Tunnel?
Hintergrund meiner Frage: Du gibst auf dem Rechner im Institut eine private IP Adresse (192.168.x.x) an. Diese sind privaten Netzen vorbehalten und dürfen nicht ins Internet geroutet werden. Weiß der Linux-Server im Institut denn, wie er über diese Adresse an Deinen Rechner bei Dir zuhause kommt?
Teils / teils. Ich gehe mti aber auch ohen VPN rein. Eine Maschine ist fei zugänglich, die anderen nur über vpn. Eine X-Anwendung bekomme ich in beiden Fällen nicht angezeigt.
Falls Du Dich von zuhause über einen VPN Tunnel mit dem Institut verbindest, sollten Dir andere helfen. Ich habe da nur geringe Kenntnisse, die auch nur theoretischer Natur sind. Meines Wissens müsste jedenfalls Deine Netzwerkadresse zuhause aus dem Netzwerk des Instituts sein und der Weg vom Institut "nach Hause" muss bekannt sein.
Falls Du Dich direkt in das Netz des Instituts verbindest (geht das überhaupt in der Postmodem Zeit?) gilt selbiges wie oben für Deine heimatliche Netzwerkadresse.
Dritter Fall: Du verbindest Dich über einen Provider mit dem Internet und baust eine normale TCP/IP Verbindung mit dem Institut auf. Dann musst Du vom Institut aus die externe IP Adresse Deiner Fritzbox verwenden (ggf. höherer Port) und auf der Fritzbox eine Port Weiterleitung zu Deinem internen Rechner definieren.
Und wie mache ich das? Liebe Gruesse Alexander -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 25.03.2012 13:18, schrieb Marcus Meissner:
On Sun, Mar 25, 2012 at 12:22:11PM +0200, alibeck wrote:
Hallo Liste,
ich kann von einer externen Maschine keine X-Fenster auf meinen lokalen Desktop anzeigen. Was habe ich gemacht:
1) xhost + access control disabled, clients can connect from any host Bei ssh -X nicht noetig und zusaetzlich unsicher.
2)
ssh -X user@remote.machine.de
3)
Linux remote:: /home/user>xterm . . . Es popt kein xterm auf. Gibt es Fehler?
Hier der Output von ssh -vvv -X ... [snip] OpenSSH_5.8p2, OpenSSL 1.0.0e 6 Sep 2011 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to login-damiana [194.94.224.100] port 22. debug1: Connection established. debug3: Incorrect RSA1 identifier debug3: Could not load "/home/ali/.ssh/id_rsa" as a RSA1 public key debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: missing keytype debug2: key_type_from_name: unknown key type 'Proc-Type:' debug3: key_read: missing keytype debug2: key_type_from_name: unknown key type 'DEK-Info:' debug3: key_read: missing keytype debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: missing keytype debug1: identity file /home/ali/.ssh/id_rsa type 1 debug1: identity file /home/ali/.ssh/id_rsa-cert type -1 debug1: identity file /home/ali/.ssh/id_dsa type -1 debug1: identity file /home/ali/.ssh/id_dsa-cert type -1 debug1: identity file /home/ali/.ssh/id_ecdsa type -1 debug1: identity file /home/ali/.ssh/id_ecdsa-cert type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3 debug1: match: OpenSSH_5.3 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.8 debug2: fd 3 setting O_NONBLOCK debug3: load_hostkeys: loading entries for host "login-damiana" from file "/home/ali/.ssh/known_hosts" debug3: load_hostkeys: found key type RSA in file /home/ali/.ssh/known_hosts:12 debug3: load_hostkeys: loaded 1 keys debug3: order_hostkeyalgs: prefer hostkeyalgs: ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-dss debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib@openssh.com debug2: kex_parse_kexinit: none,zlib@openssh.com debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_setup: found hmac-md5 debug1: kex: server->client aes128-ctr hmac-md5 none debug2: mac_setup: found hmac-md5 debug1: kex: client->server aes128-ctr hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug2: dh_gen_key: priv key bits set: 120/256 debug2: bits set: 511/1024 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Server host key: RSA 79:ee:9c:2e:a2:cf:dd:7c:f1:6e:cd:fa:7d:1d:9c:46 debug3: load_hostkeys: loading entries for host "login-damiana" from file "/home/ali/.ssh/known_hosts" debug3: load_hostkeys: found key type RSA in file /home/ali/.ssh/known_hosts:12 debug3: load_hostkeys: loaded 1 keys debug3: load_hostkeys: loading entries for host "194.94.224.100" from file "/home/ali/.ssh/known_hosts" debug3: load_hostkeys: found key type RSA in file /home/ali/.ssh/known_hosts:9 debug3: load_hostkeys: loaded 1 keys debug1: Host 'login-damiana' is known and matches the RSA host key. debug1: Found key in /home/ali/.ssh/known_hosts:12 debug2: bits set: 510/1024 debug1: ssh_rsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /home/ali/.ssh/id_rsa (0x7f9f13a70ff0) debug2: key: /home/ali/.ssh/id_dsa ((nil)) debug2: key: /home/ali/.ssh/id_ecdsa ((nil)) debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,hostbased debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,hostbased debug3: preferred publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Offering RSA public key: /home/ali/.ssh/id_rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Server accepts key: pkalg ssh-rsa blen 277 debug2: input_userauth_pk_ok: fp 48:ec:5d:e8:a7:cf:64:83:8e:4f:52:a0:fb:11:ca:a5 debug3: sign_and_send_pubkey: RSA 48:ec:5d:e8:a7:cf:64:83:8e:4f:52:a0:fb:11:ca:a5 debug1: key_parse_private_pem: PEM_read_PrivateKey failed debug1: read PEM private key done: type <unknown> Enter passphrase for key '/home/ali/.ssh/id_rsa': debug1: read PEM private key done: type RSA debug1: Authentication succeeded (publickey). Authenticated to login-damiana ([194.94.224.100]:22). debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug2: channel 0: send open debug1: Requesting no-more-sessions@openssh.com debug1: Entering interactive session. debug2: callback start debug2: x11_get_proto: /usr/bin/xauth list :0 2>/dev/null debug1: Requesting X11 forwarding with authentication spoofing. debug2: channel 0: request x11-req confirm 0 debug2: client_session2_setup: id 0 debug2: fd 3 setting TCP_NODELAY debug3: packet_set_tos: set IP_TOS 0x10 debug2: channel 0: request pty-req confirm 1 debug1: Sending environment. debug3: Ignored env LESSKEY debug3: Ignored env XDG_VTNR debug3: Ignored env MANPATH debug3: Ignored env NNTPSERVER debug3: Ignored env SSH_AGENT_PID debug3: Ignored env KDE_MULTIHEAD debug3: Ignored env XDG_SESSION_ID debug3: Ignored env DM_CONTROL debug3: Ignored env HOSTNAME debug3: Ignored env MALLOC_CHECK_ debug3: Ignored env XKEYSYMDB debug3: Ignored env GPG_AGENT_INFO debug3: Ignored env TERM debug3: Ignored env SHELL debug3: Ignored env HOST debug3: Ignored env HISTSIZE debug3: Ignored env XDG_SESSION_COOKIE debug3: Ignored env CATALINA_HOME debug3: Ignored env XDM_MANAGED debug3: Ignored env PROFILEREAD debug3: Ignored env GTK2_RC_FILES debug3: Ignored env KONSOLE_DBUS_SERVICE debug3: Ignored env TMPDIR debug3: Ignored env GTK_RC_FILES debug3: Ignored env GS_LIB debug3: Ignored env WINDOWID debug3: Ignored env MORE debug3: Ignored env X509_CERT_DIR debug3: Ignored env XSESSION_IS_UP debug3: Ignored env SHELL_SESSION_ID debug3: Ignored env ANT_HOME debug3: Ignored env KDE_FULL_SESSION debug3: Ignored env USER debug3: Ignored env JRE_HOME debug3: Ignored env LS_COLORS debug3: Ignored env LD_LIBRARY_PATH debug3: Ignored env PILOTPORT debug3: Ignored env XNLSPATH debug3: Ignored env HOSTTYPE debug3: Ignored env SSH_AUTH_SOCK debug3: Ignored env FROM_HEADER debug3: Ignored env SESSION_MANAGER debug3: Ignored env CONFIG_SITE debug3: Ignored env PAGER debug3: Ignored env CSHEDIT debug3: Ignored env system debug3: Ignored env XDG_CONFIG_DIRS debug3: Ignored env MINICOM debug3: Ignored env DESKTOP_SESSION debug3: Ignored env PATH debug3: Ignored env MAIL debug3: Ignored env CPU debug3: Ignored env QT_IM_MODULE debug3: Ignored env JAVA_BINDIR debug3: Ignored env PWD debug3: Ignored env INPUTRC debug3: Ignored env XMODIFIERS debug3: Ignored env JAVA_HOME debug1: Sending env LANG = de_DE.UTF-8 debug2: channel 0: request env confirm 0 debug3: Ignored env KDE_SESSION_UID debug3: Ignored env FCEDIT debug3: Ignored env PYTHONSTARTUP debug3: Ignored env SDK_HOME debug3: Ignored env PS1 debug3: Ignored env KONSOLE_DBUS_SESSION debug3: Ignored env SSH_ASKPASS debug3: Ignored env MALLOC_PERTURB_ debug3: Ignored env GPG_TTY debug3: Ignored env JDK_HOME debug3: Ignored env COLORFGBG debug3: Ignored env QT_SYSTEM_DIR debug3: Ignored env SHLVL debug3: Ignored env XDG_SEAT debug3: Ignored env HOME debug3: Ignored env OSTYPE debug3: Ignored env KDE_SESSION_VERSION debug3: Ignored env ALSA_CONFIG_PATH debug3: Ignored env SDL_AUDIODRIVER debug3: Ignored env LANGUAGE debug3: Ignored env LESS_ADVANCED_PREPROCESSOR debug3: Ignored env LS_OPTIONS debug3: Ignored env XCURSOR_THEME debug3: Ignored env WINDOWMANAGER debug3: Ignored env GAT_LOCATION debug3: Ignored env LESS debug3: Ignored env G_FILENAME_ENCODING debug3: Ignored env LOGNAME debug3: Ignored env MACHTYPE debug3: Ignored env VISUAL debug3: Ignored env CVS_RSH debug3: Ignored env GAT_ADAPTOR_PATH debug3: Ignored env GADDIR debug3: Ignored env KDE_NETWORKMANAGER_DISABLED debug3: Ignored env DBUS_SESSION_BUS_ADDRESS debug3: Ignored env XDG_DATA_DIRS debug3: Ignored env LESSOPEN debug3: Ignored env USE_FAM debug3: Ignored env WINDOWPATH debug3: Ignored env PROFILEHOME debug3: Ignored env XDG_RUNTIME_DIR debug3: Ignored env DISPLAY debug3: Ignored env QT_PLUGIN_PATH debug3: Ignored env GTK_IM_MODULE debug3: Ignored env XAUTHLOCALHOSTNAME debug3: Ignored env LESSCLOSE debug3: Ignored env QT_IM_SWITCHER debug3: Ignored env G_BROKEN_FILENAMES debug3: Ignored env COLORTERM debug3: Ignored env JAVA_ROOT debug3: Ignored env mc debug3: Ignored env _ debug2: channel 0: request shell confirm 1 debug2: callback done debug2: channel 0: open confirm rwindow 0 rmax 32768 debug2: channel_input_status_confirm: type 99 id 0 debug2: PTY allocation request accepted on channel 0 debug2: channel 0: rcvd adjust 2097152 debug2: channel_input_status_confirm: type 99 id 0 debug2: shell request accepted on channel 0 Last login: Mon Mar 26 20:27:57 2012 from vpn-external-002.dest.de [snip] Danach setze ich dann ein xterm ab, und es kommt nur: [snip] xterm debug1: client_input_channel_open: ctype x11 rchan 3 win 65536 max 16384 debug1: client_request_x11: request from 127.0.0.1 58654 debug2: fd 7 setting O_NONBLOCK debug3: fd 7 is O_NONBLOCK debug1: channel 1: new [x11] debug1: confirm x11 debug2: channel 1: rcvd adjust 45376 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49024 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 33140 debug2: channel 1: rcvd adjust 32832 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 35328 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 46932 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 46080 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 36084 debug2: channel 1: rcvd adjust 32864 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49024 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 36412 [snip]
Bei ssh -X user@remote.machine.de wird ein "DISPLAY" gesetzt, was dann ueber das ssh zurueck getunnelt wird. Sprich in Schritt 2 ein "echo $DISPLAY" was dann da gesetzt sein sollte.
Und da gibt es als DISPLAY: localhost:11.0 Kann also nicht funktionieren. Die Frage ist nur, warum ist die DISPLAY-Variable so, sie soll doch surch ssh -X richtig gesetzt werden, oder? Übrigens habe ich ohen VPN-Tunnel eine Display-Variable derselben From auf den externen Host. Es scheint also an einer Einstellung der Frtzbox zu liegen, aber an welcher? Liebe Grüße Alexander -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo Liste, das X-Forwadding funktioniert bei mir leider nicht, wenn ich über einen Router an eine externe Maschine gehe, und dort z.B. ein xterm starte. Das xterm wird nicht lokal auf meinem Rechner angezeigt. Ich habe das Problem sowohl mit und ohne VPN. Es muss etwas mit den Routereinstellungen zu tun haben. Hier der Output von ssh -vvv -X user@remotehost [snip] OpenSSH_5.8p2, OpenSSL 1.0.0e 6 Sep 2011 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to login-damiana [194.94.224.100] port 22. debug1: Connection established. debug3: Incorrect RSA1 identifier debug3: Could not load "/home/ali/.ssh/id_rsa" as a RSA1 public key debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: missing keytype debug2: key_type_from_name: unknown key type 'Proc-Type:' debug3: key_read: missing keytype debug2: key_type_from_name: unknown key type 'DEK-Info:' debug3: key_read: missing keytype debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: missing keytype debug1: identity file /home/ali/.ssh/id_rsa type 1 debug1: identity file /home/ali/.ssh/id_rsa-cert type -1 debug1: identity file /home/ali/.ssh/id_dsa type -1 debug1: identity file /home/ali/.ssh/id_dsa-cert type -1 debug1: identity file /home/ali/.ssh/id_ecdsa type -1 debug1: identity file /home/ali/.ssh/id_ecdsa-cert type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3 debug1: match: OpenSSH_5.3 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.8 debug2: fd 3 setting O_NONBLOCK debug3: load_hostkeys: loading entries for host "login-damiana" from file "/home/ali/.ssh/known_hosts" debug3: load_hostkeys: found key type RSA in file /home/ali/.ssh/known_hosts:12 debug3: load_hostkeys: loaded 1 keys debug3: order_hostkeyalgs: prefer hostkeyalgs: ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-dss debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib@openssh.com debug2: kex_parse_kexinit: none,zlib@openssh.com debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_setup: found hmac-md5 debug1: kex: server->client aes128-ctr hmac-md5 none debug2: mac_setup: found hmac-md5 debug1: kex: client->server aes128-ctr hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug2: dh_gen_key: priv key bits set: 120/256 debug2: bits set: 511/1024 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Server host key: RSA 79:ee:9c:2e:a2:cf:dd:7c:f1:6e:cd:fa:7d:1d:9c:46 debug3: load_hostkeys: loading entries for host "login-damiana" from file "/home/ali/.ssh/known_hosts" debug3: load_hostkeys: found key type RSA in file /home/ali/.ssh/known_hosts:12 debug3: load_hostkeys: loaded 1 keys debug3: load_hostkeys: loading entries for host "194.94.224.100" from file "/home/ali/.ssh/known_hosts" debug3: load_hostkeys: found key type RSA in file /home/ali/.ssh/known_hosts:9 debug3: load_hostkeys: loaded 1 keys debug1: Host 'login-damiana' is known and matches the RSA host key. debug1: Found key in /home/ali/.ssh/known_hosts:12 debug2: bits set: 510/1024 debug1: ssh_rsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /home/ali/.ssh/id_rsa (0x7f9f13a70ff0) debug2: key: /home/ali/.ssh/id_dsa ((nil)) debug2: key: /home/ali/.ssh/id_ecdsa ((nil)) debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,hostbased debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,hostbased debug3: preferred publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Offering RSA public key: /home/ali/.ssh/id_rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Server accepts key: pkalg ssh-rsa blen 277 debug2: input_userauth_pk_ok: fp 48:ec:5d:e8:a7:cf:64:83:8e:4f:52:a0:fb:11:ca:a5 debug3: sign_and_send_pubkey: RSA 48:ec:5d:e8:a7:cf:64:83:8e:4f:52:a0:fb:11:ca:a5 debug1: key_parse_private_pem: PEM_read_PrivateKey failed debug1: read PEM private key done: type <unknown> Enter passphrase for key '/home/ali/.ssh/id_rsa': debug1: read PEM private key done: type RSA debug1: Authentication succeeded (publickey). Authenticated to login-damiana ([194.94.224.100]:22). debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug2: channel 0: send open debug1: Requesting no-more-sessions@openssh.com debug1: Entering interactive session. debug2: callback start debug2: x11_get_proto: /usr/bin/xauth list :0 2>/dev/null debug1: Requesting X11 forwarding with authentication spoofing. debug2: channel 0: request x11-req confirm 0 debug2: client_session2_setup: id 0 debug2: fd 3 setting TCP_NODELAY debug3: packet_set_tos: set IP_TOS 0x10 debug2: channel 0: request pty-req confirm 1 debug1: Sending environment. debug3: Ignored env LESSKEY debug3: Ignored env XDG_VTNR debug3: Ignored env MANPATH debug3: Ignored env NNTPSERVER debug3: Ignored env SSH_AGENT_PID debug3: Ignored env KDE_MULTIHEAD debug3: Ignored env XDG_SESSION_ID debug3: Ignored env DM_CONTROL debug3: Ignored env HOSTNAME debug3: Ignored env MALLOC_CHECK_ debug3: Ignored env XKEYSYMDB debug3: Ignored env GPG_AGENT_INFO debug3: Ignored env TERM debug3: Ignored env SHELL debug3: Ignored env HOST debug3: Ignored env HISTSIZE debug3: Ignored env XDG_SESSION_COOKIE debug3: Ignored env CATALINA_HOME debug3: Ignored env XDM_MANAGED debug3: Ignored env PROFILEREAD debug3: Ignored env GTK2_RC_FILES debug3: Ignored env KONSOLE_DBUS_SERVICE debug3: Ignored env TMPDIR debug3: Ignored env GTK_RC_FILES debug3: Ignored env GS_LIB debug3: Ignored env WINDOWID debug3: Ignored env MORE debug3: Ignored env X509_CERT_DIR debug3: Ignored env XSESSION_IS_UP debug3: Ignored env SHELL_SESSION_ID debug3: Ignored env ANT_HOME debug3: Ignored env KDE_FULL_SESSION debug3: Ignored env USER debug3: Ignored env JRE_HOME debug3: Ignored env LS_COLORS debug3: Ignored env LD_LIBRARY_PATH debug3: Ignored env PILOTPORT debug3: Ignored env XNLSPATH debug3: Ignored env HOSTTYPE debug3: Ignored env SSH_AUTH_SOCK debug3: Ignored env FROM_HEADER debug3: Ignored env SESSION_MANAGER debug3: Ignored env CONFIG_SITE debug3: Ignored env PAGER debug3: Ignored env CSHEDIT debug3: Ignored env system debug3: Ignored env XDG_CONFIG_DIRS debug3: Ignored env MINICOM debug3: Ignored env DESKTOP_SESSION debug3: Ignored env PATH debug3: Ignored env MAIL debug3: Ignored env CPU debug3: Ignored env QT_IM_MODULE debug3: Ignored env JAVA_BINDIR debug3: Ignored env PWD debug3: Ignored env INPUTRC debug3: Ignored env XMODIFIERS debug3: Ignored env JAVA_HOME debug1: Sending env LANG = de_DE.UTF-8 debug2: channel 0: request env confirm 0 debug3: Ignored env KDE_SESSION_UID debug3: Ignored env FCEDIT debug3: Ignored env PYTHONSTARTUP debug3: Ignored env SDK_HOME debug3: Ignored env PS1 debug3: Ignored env KONSOLE_DBUS_SESSION debug3: Ignored env SSH_ASKPASS debug3: Ignored env MALLOC_PERTURB_ debug3: Ignored env GPG_TTY debug3: Ignored env JDK_HOME debug3: Ignored env COLORFGBG debug3: Ignored env QT_SYSTEM_DIR debug3: Ignored env SHLVL debug3: Ignored env XDG_SEAT debug3: Ignored env HOME debug3: Ignored env OSTYPE debug3: Ignored env KDE_SESSION_VERSION debug3: Ignored env ALSA_CONFIG_PATH debug3: Ignored env SDL_AUDIODRIVER debug3: Ignored env LANGUAGE debug3: Ignored env LESS_ADVANCED_PREPROCESSOR debug3: Ignored env LS_OPTIONS debug3: Ignored env XCURSOR_THEME debug3: Ignored env WINDOWMANAGER debug3: Ignored env GAT_LOCATION debug3: Ignored env LESS debug3: Ignored env G_FILENAME_ENCODING debug3: Ignored env LOGNAME debug3: Ignored env MACHTYPE debug3: Ignored env VISUAL debug3: Ignored env CVS_RSH debug3: Ignored env GAT_ADAPTOR_PATH debug3: Ignored env GADDIR debug3: Ignored env KDE_NETWORKMANAGER_DISABLED debug3: Ignored env DBUS_SESSION_BUS_ADDRESS debug3: Ignored env XDG_DATA_DIRS debug3: Ignored env LESSOPEN debug3: Ignored env USE_FAM debug3: Ignored env WINDOWPATH debug3: Ignored env PROFILEHOME debug3: Ignored env XDG_RUNTIME_DIR debug3: Ignored env DISPLAY debug3: Ignored env QT_PLUGIN_PATH debug3: Ignored env GTK_IM_MODULE debug3: Ignored env XAUTHLOCALHOSTNAME debug3: Ignored env LESSCLOSE debug3: Ignored env QT_IM_SWITCHER debug3: Ignored env G_BROKEN_FILENAMES debug3: Ignored env COLORTERM debug3: Ignored env JAVA_ROOT debug3: Ignored env mc debug3: Ignored env _ debug2: channel 0: request shell confirm 1 debug2: callback done debug2: channel 0: open confirm rwindow 0 rmax 32768 debug2: channel_input_status_confirm: type 99 id 0 debug2: PTY allocation request accepted on channel 0 debug2: channel 0: rcvd adjust 2097152 debug2: channel_input_status_confirm: type 99 id 0 debug2: shell request accepted on channel 0 Last login: Mon Mar 26 20:27:57 2012 from vpn-external-002.dest.de [snip] Danach setze ich dann ein xterm ab, und es kommt nur: [snip] xterm debug1: client_input_channel_open: ctype x11 rchan 3 win 65536 max 16384 debug1: client_request_x11: request from 127.0.0.1 58654 debug2: fd 7 setting O_NONBLOCK debug3: fd 7 is O_NONBLOCK debug1: channel 1: new [x11] debug1: confirm x11 debug2: channel 1: rcvd adjust 45376 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49024 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 33140 debug2: channel 1: rcvd adjust 32832 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 35328 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 46932 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 46080 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 36084 debug2: channel 1: rcvd adjust 32864 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 49024 debug2: channel 1: rcvd adjust 49152 debug2: channel 1: rcvd adjust 36412 [snip] So geht es weiter, und das xterm-Fenster erscheint nicht auf meinem lokalen Monitor. Ein Hinweis für eine Fehlkonfiguration der Fritzbox glaube ich, hier gefunden zu haben. Ein echo $DISPLAY auf dem remote host liefert: localhost:11.0 Kann also nicht funktionieren. Die Frage ist nur, warum ist die DISPLAY-Variable so, sie soll doch surch ssh -X richtig gesetzt werden, oder? Übrigens habe ich ohne VPN-Tunnel eine Display-Variable derselben From auf den externen Host. Es scheint also an einer Einstellung der Frtzbox zu liegen, aber an welcher? Liebe Grüße Alexander -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 26.03.2012 15:20, schrieb alexander.beck-ratzka:
Am 3/26/2012 2:20 PM, schrieb Ralf Arndt:
Dritter Fall: Du verbindest Dich über einen Provider mit dem Internet und baust eine normale TCP/IP Verbindung mit dem Institut auf. Dann musst Du vom Institut aus die externe IP Adresse Deiner Fritzbox verwenden (ggf. höherer Port) und auf der Fritzbox eine Port Weiterleitung zu Deinem internen Rechner definieren.
Und wie mache ich das?
Ich vermute mal, das X Display soll den SSH Tunnel verwenden, den Du von zuhause aufgebaut hast. Da habe ich keine Ahnung und kann ich Dir nicht wirklich helfen. Ich kann Dir höchstens ein paar rudimentäre Tipps zu einem Zugriff von außen auf Deinen internen Rechner liefern. 1. Du richtest auf der Fritzbox eine Weiterleitung eines Ports der Fritzbox (Beispiel 22222) auf einen Port Deines internen Rechners ein. Wahrscheinlich musst Du auf der Fritzbox die Experten Ansicht aktivieren und findest die Weiterleitung unter "Netzwerk" oder "Erweitert" -> "Netzwerk" Als Zielport gibst Du den Port an, auf dem die jeweilige Anwendung Deines internen Rechners lauscht (Beispiel 22 (Standardeinstellung für SSH)). 2. Du ermittelst die externe IP Adresse Deines DSL Routers (Beispiel 123.123.123.123). Dauerhaft ist eine Lösung ala DynDNS natürlich besser. 3. Für den Zugriff von extern gibst Du die externe IP Adresse Deines DSL Routers und den weiter zu leitenden Port an (Beispiel 123.123.123.123:22222). Grüße Ralf -- Antworten bitte nur in die Mailingliste! PMs bitte an: listpm (@) arndt-de (.) eu -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Alexander Beck-Ratzka wrote:
das X-Forwadding funktioniert bei mir leider nicht, wenn ich über einen Router an eine externe Maschine gehe, und dort z.B. ein xterm starte. Das xterm wird nicht lokal auf meinem Rechner angezeigt. Ich habe das Problem sowohl mit und ohne VPN. Es muss etwas mit den Routereinstellungen zu tun haben. [...] Last login: Mon Mar 26 20:27:57 2012 from vpn-external-002.dest.de [snip]
Danach setze ich dann ein xterm ab, und es kommt nur:
[snip] xterm debug1: client_input_channel_open: ctype x11 rchan 3 win 65536 max 16384 debug1: client_request_x11: request from 127.0.0.1 58654 debug2: fd 7 setting O_NONBLOCK debug3: fd 7 is O_NONBLOCK debug1: channel 1: new [x11] debug1: confirm x11 debug2: channel 1: rcvd adjust 45376 ... [snip]
So geht es weiter, und das xterm-Fenster erscheint nicht auf meinem lokalen Monitor.
Ein Hinweis für eine Fehlkonfiguration der Fritzbox glaube ich, hier gefunden zu haben. Ein echo $DISPLAY auf dem remote host liefert:
localhost:11.0
Nee, das sieht bei mir genau so aus. Und ist auch korrekt so. Bei mir werden auf dem PC (auch 'ne 12.1) die Fenster sowohl von den "grossen" Firmenrechnern im LAN (hinter diversen Routern/ Firwalls) als auch von meinem Home-Server (hinter Tunnel und Fritz-Box) angezeigt.
Kann also nicht funktionieren. Die Frage ist nur, warum ist die DISPLAY-Variable so, sie soll doch surch ssh -X richtig gesetzt werden, oder?
Ist sie ja; dein Problem muss woanders liegen. Bei mir wird nach dem Aufruf des xterms im Debug Output nach den Zeilen - debug1: channel 1: new [x11] - debug1: confirm x11 NICHT das hier angezeigt - da würde ich mal nachhaken: - debug2: channel 1: rcvd adjust 45376 Andreas Andreas -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
On Tuesday 27 March 2012 10:00:36 Kyek, Andreas, VF-DE wrote:
Alexander Beck-Ratzka wrote:
das X-Forwadding funktioniert bei mir leider nicht, wenn ich über einen Router an eine externe Maschine gehe, und dort z.B. ein xterm starte. Das xterm wird nicht lokal auf meinem Rechner angezeigt. Ich habe das Problem sowohl mit und ohne VPN. Es muss etwas mit den Routereinstellungen zu tun haben.
[...]
Last login: Mon Mar 26 20:27:57 2012 from vpn-external-002.dest.de [snip]
Danach setze ich dann ein xterm ab, und es kommt nur:
[snip] xterm debug1: client_input_channel_open: ctype x11 rchan 3 win 65536 max 16384 debug1: client_request_x11: request from 127.0.0.1 58654 debug2: fd 7 setting O_NONBLOCK debug3: fd 7 is O_NONBLOCK debug1: channel 1: new [x11] debug1: confirm x11 debug2: channel 1: rcvd adjust 45376
...
[snip]
So geht es weiter, und das xterm-Fenster erscheint nicht auf meinem lokalen Monitor.
Ein Hinweis für eine Fehlkonfiguration der Fritzbox glaube ich, hier gefunden zu haben. Ein echo $DISPLAY auf dem remote host liefert:
localhost:11.0
Nee, das sieht bei mir genau so aus. Und ist auch korrekt so. Bei mir werden auf dem PC (auch 'ne 12.1) die Fenster sowohl von den "grossen" Firmenrechnern im LAN (hinter diversen Routern/ Firwalls) als auch von meinem Home-Server (hinter Tunnel und Fritz-Box) angezeigt.
Kann also nicht funktionieren. Die Frage ist nur, warum ist die DISPLAY-Variable so, sie soll doch surch ssh -X richtig gesetzt werden, oder?
Ist sie ja; dein Problem muss woanders liegen.
Bei mir wird nach dem Aufruf des xterms im Debug Output nach den Zeilen - debug1: channel 1: new [x11] - debug1: confirm x11 NICHT das hier angezeigt - da würde ich mal nachhaken: - debug2: channel 1: rcvd adjust 45376
Da habe ich mit schnon einen Elch gesucht, leider ohne wirklich einen Hinweis gefunden zu haben. Ist halt ein Zeichen dafür, dass das X-Forwarding nicht funzt, und das merke ich ja auch schon so :-) Könnte es sein, das OpenSuSE 12.1 in der Dfault-Einstellung das X-Dorwadding von einem remote host abblockt? Das muss doch irgendwo konfiguriert sein. Wo werde ich hier fündig? Liebe Grüße Alexander -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
On Tue, Mar 27, 2012 at 10:55:41AM +0200, Alexander Beck-Ratzka wrote:
Da habe ich mit schnon einen Elch gesucht, leider ohne wirklich einen Hinweis gefunden zu haben. Ist halt ein Zeichen dafür, dass das X-Forwarding nicht funzt, und das merke ich ja auch schon so :-)
Könnte es sein, das OpenSuSE 12.1 in der Dfault-Einstellung das X-Dorwadding von einem remote host abblockt? Das muss doch irgendwo konfiguriert sein. Wo werde ich hier fündig?
Verwende einen ssh-Tunnel. Ansonsten gibt's in /etc/sysconfig/displaymanager DISPLAYMANAGER_XSERVER_TCP_PORT_6000_OPEN, aber dann wirst Du mit Sicherheit regelmäßig von Bots auf Port 6000+ gescant. Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
On Tuesday 27 March 2012 11:07:35 Dr. Werner Fink wrote:
On Tue, Mar 27, 2012 at 10:55:41AM +0200, Alexander Beck-Ratzka wrote:
Da habe ich mit schnon einen Elch gesucht, leider ohne wirklich einen Hinweis gefunden zu haben. Ist halt ein Zeichen dafür, dass das X-Forwarding nicht funzt, und das merke ich ja auch schon so :-)
Könnte es sein, das OpenSuSE 12.1 in der Dfault-Einstellung das X-Dorwadding von einem remote host abblockt? Das muss doch irgendwo konfiguriert sein. Wo werde ich hier fündig?
Verwende einen ssh-Tunnel. Ansonsten gibt's in /etc/sysconfig/displaymanager DISPLAYMANAGER_XSERVER_TCP_PORT_6000_OPEN, aber dann wirst Du mit Sicherheit regelmäßig von Bots auf Port 6000+ gescant.
Ob ich einen ssh-Tunnel verwende, da bin ich mir nicht so ganz sicher. Ich gehe über einen Router raus (Fritzbox), und zwar ssh -X. Auf dem remote host habe ich dann eine DISPLAY-Variable der Form: localhost:11 aber ein xterm wird mir nicht angezeigt. Falls das noch kein ssh-Tunnel ist, wie stelle ich denn diesen ein? Liebe Grüße Alexander -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 03/27/2012 11:29 AM, schrieb Alexander Beck-Ratzka:
On Tuesday 27 March 2012 11:07:35 Dr. Werner Fink wrote:
On Tue, Mar 27, 2012 at 10:55:41AM +0200, Alexander Beck-Ratzka wrote:
Da habe ich mit schnon einen Elch gesucht, leider ohne wirklich einen Hinweis gefunden zu haben. Ist halt ein Zeichen dafür, dass das X-Forwarding nicht funzt, und das merke ich ja auch schon so :-)
Könnte es sein, das OpenSuSE 12.1 in der Dfault-Einstellung das X-Dorwadding von einem remote host abblockt? Das muss doch irgendwo konfiguriert sein. Wo werde ich hier fündig?
Verwende einen ssh-Tunnel. Ansonsten gibt's in /etc/sysconfig/displaymanager DISPLAYMANAGER_XSERVER_TCP_PORT_6000_OPEN, aber dann wirst Du mit Sicherheit regelmäßig von Bots auf Port 6000+ gescant.
Ob ich einen ssh-Tunnel verwende, da bin ich mir nicht so ganz sicher. Ich gehe über einen Router raus (Fritzbox), und zwar ssh -X. Auf dem remote host habe ich dann eine DISPLAY-Variable der Form:
localhost:11
aber ein xterm wird mir nicht angezeigt.
Falls das noch kein ssh-Tunnel ist, wie stelle ich denn diesen ein?
Liebe Grüße
Alexander
/etc/ssh/sshd_config X11Forwarding yes Gruß Daniel -- Daniel Spannbauer Software Entwicklung marco Systemanalyse und Entwicklung GmbH Tel +49 8333 9233-27 Fax -11 Rechbergstr. 4 - 6, D 87727 Babenhausen Mobil +49 171 4033220 http://www.marco.de/ Email ds@marco.de Geschäftsführer Martin Reuter HRB 171775 Amtsgericht München -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
On Tuesday 27 March 2012 11:37:04 Daniel Spannbauer wrote:
Am 03/27/2012 11:29 AM, schrieb Alexander Beck-Ratzka:
On Tuesday 27 March 2012 11:07:35 Dr. Werner Fink wrote:
On Tue, Mar 27, 2012 at 10:55:41AM +0200, Alexander Beck-Ratzka wrote:
Da habe ich mit schnon einen Elch gesucht, leider ohne wirklich einen Hinweis gefunden zu haben. Ist halt ein Zeichen dafür, dass das X-Forwarding nicht funzt, und das merke ich ja auch schon so :-)
Könnte es sein, das OpenSuSE 12.1 in der Dfault-Einstellung das X-Dorwadding von einem remote host abblockt? Das muss doch irgendwo konfiguriert sein. Wo werde ich hier fündig?
Verwende einen ssh-Tunnel. Ansonsten gibt's in /etc/sysconfig/displaymanager DISPLAYMANAGER_XSERVER_TCP_PORT_6000_OPEN, aber dann wirst Du mit Sicherheit regelmäßig von Bots auf Port 6000+ gescant.
Ob ich einen ssh-Tunnel verwende, da bin ich mir nicht so ganz sicher. Ich gehe über einen Router raus (Fritzbox), und zwar ssh -X. Auf dem remote host habe ich dann eine DISPLAY-Variable der Form:
localhost:11
aber ein xterm wird mir nicht angezeigt.
Falls das noch kein ssh-Tunnel ist, wie stelle ich denn diesen ein?
Liebe Grüße
Alexander
/etc/ssh/sshd_config
X11Forwarding yes
Das habe ich! Liebe Grüße Alexander -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
[snip]
/etc/ssh/sshd_config
X11Forwarding yes
Das habe ich!
Also ich hatte das Problem einmal, als ich IPv6 deaktiviert hatte. -- Matthias -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo, Am Tue, 27 Mar 2012, Alexander Beck-Ratzka schrieb:
/etc/ssh/sshd_config
X11Forwarding yes
Das habe ich!
Läuft dein X mglw. mit '-nolisten tcp'? -dnh -- 9: GUI Ein Hintergrundbild und 12 Xterms (Kristian Köhntopp) -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
On Tuesday 27 March 2012 18:37:12 David Haller wrote:
Hallo,
Am Tue, 27 Mar 2012, Alexander Beck-Ratzka schrieb:
/etc/ssh/sshd_config
X11Forwarding yes
Das habe ich!
Läuft dein X mglw. mit '-nolisten tcp'?
Weiß ich nicht, wie kriege ich das raus? Liebe Grüße Alexander -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
On Tuesday 27 March 2012 18:24:54 Matthias Praunegger wrote:
[snip]
/etc/ssh/sshd_config
X11Forwarding yes
Das habe ich!
Also ich hatte das Problem einmal, als ich IPv6 deaktiviert hatte.
Das ist mal ein Hinweis. Meines Wissens ist das bei mir deaktiviert, kann ich allerdings erst heute abend überprüfen, denn es handelt sich um meinen Desktop zu Hause. Liebe Grüße Alexander -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 27.03.2012 18:37, schrieb David Haller:
Hallo,
Am Tue, 27 Mar 2012, Alexander Beck-Ratzka schrieb:
/etc/ssh/sshd_config
X11Forwarding yes Das habe ich! Läuft dein X mglw. mit '-nolisten tcp'?
-dnh
Läuft er nicht, in kdmrc in /usr/share/kde4/config/kdm ist die Zeile #ServerArgsLocal=-nolisten tcp eben auskommentiert. Mir ist allerdings nicht klar, was das bedeutet. Liebe Grüße Alexander -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo, Am Wed, 28 Mar 2012, alibeck schrieb:
Läuft er nicht, in kdmrc in /usr/share/kde4/config/kdm ist die Zeile
#ServerArgsLocal=-nolisten tcp
eben auskommentiert. Mir ist allerdings nicht klar, was das bedeutet.
ps -e -o cmd | grep ^X HTH, -dnh -- Coffee not found: user halted -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
On Wednesday 28 March 2012 22:15:45 David Haller wrote:
Hallo,
Am Wed, 28 Mar 2012, alibeck schrieb:
Läuft er nicht, in kdmrc in /usr/share/kde4/config/kdm ist die Zeile
#ServerArgsLocal=-nolisten tcp
eben auskommentiert. Mir ist allerdings nicht klar, was das bedeutet.
ps -e -o cmd | grep ^X
Ich fürchte, ich bin falsch verstanden worden; ich wollte lediglich wissen, ob kein -nolisten tcp bewirken kann, dass es mit dem X-Forwarding nicht klappt. Obiges ps-Kommando zeigt jedenfalls nichts an. Ich habe inzwischen auch man den Laptop von meinem Arbeitsplatz, mit welchem mit ssh-X im LAN des Instituts X-Forwarding klappt zu Hause an meine Fritzbox gehängt, und nix ist mit X-Forwarding. Es sieht also ganz so aus, als läge es an der Router-Einstellung. Ich werde hierzu gleich einen neuen Thread aufmachen. Liebe Grüße Alexander -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
On Thu, Mar 29, 2012 at 09:00:07AM +0200, Alexander Beck-Ratzka wrote:
On Wednesday 28 March 2012 22:15:45 David Haller wrote:
Am Wed, 28 Mar 2012, alibeck schrieb:
Läuft er nicht, in kdmrc in /usr/share/kde4/config/kdm ist die Zeile
#ServerArgsLocal=-nolisten tcp
eben auskommentiert. Mir ist allerdings nicht klar, was das bedeutet.
ps -e -o cmd | grep ^X
Bei mir kommt damit keine Ausgabe, nur mit ps -e -o cmd | grep X erscheint u.a. /usr/bin/Xorg :0 -br -verbose -logverbose 7 -auth /var/run/gdm/auth-for-gdm-dTxWLb/database -nolisten tcp vt7
Ich fürchte, ich bin falsch verstanden worden; ich wollte lediglich wissen, ob kein -nolisten tcp bewirken kann, dass es mit dem X-Forwarding nicht klappt.
Fast. Es bewirkt daß dein X-Forwarding nicht klappt. flo -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo, Am Thu, 29 Mar 2012, Florian Groß schrieb:
On Thu, Mar 29, 2012 at 09:00:07AM +0200, Alexander Beck-Ratzka wrote:
On Wednesday 28 March 2012 22:15:45 David Haller wrote:
Am Wed, 28 Mar 2012, alibeck schrieb:
Läuft er nicht, in kdmrc in /usr/share/kde4/config/kdm ist die Zeile
#ServerArgsLocal=-nolisten tcp
eben auskommentiert. Mir ist allerdings nicht klar, was das bedeutet.
ps -e -o cmd | grep ^X
Bei mir kommt damit keine Ausgabe, nur mit
ps -e -o cmd | grep X
erscheint u.a. /usr/bin/Xorg :0 -br -verbose -logverbose 7 -auth /var/run/gdm/auth-for-gdm-dTxWLb/database -nolisten tcp vt7
Zeltzam. Hier auf ner 12.1 kommt z.B.: X :0 -auth /home/dh/.serverauth.2825 -nolisten tcp wobei ich wie gewohnt nicht via RL5 + displaymanager starte sondern via RL3 + startx. Also kein Pfad zu X. Und hier bekomme ich z.B. trotz 'X11Forwarding yes' in der sshd.conf mit dem -nolisten tcp ein $ ssh -X localhost xterm Password: setterm: $TERM is not defined. /usr/bin/xterm Xt error: Can't open display: /usr/bin/xterm: DISPLAY is not set Und dazu diese Log-Zeile: sshd[11205]: error: Failed to allocate internet-domain X11 display socket Soviel zum '-nolisten tcp' ;) Das 'X11Forwarding yes' wurde von Daniel ja schon in 'Date: Tue, 27 Mar 2012 11:37:04 +0200' genannt, wenn auch anscheinend (siehe anderen Thread heute) von Alexander überlesen. -dnh -- Perl is the successful attempt to make a braindump executable. -- Lutz Donnerhacke -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
participants (11)
-
Alexander Beck-Ratzka -
alexander.beck-ratzka
-
alibeck
-
Daniel Spannbauer -
David Haller -
Dr. Werner Fink -
Florian Groß -
Kyek, Andreas, VF-DE -
Marcus Meissner -
Matthias Praunegger -
Ralf Arndt