Dotaz: ssh -X nechodi

[asym]

Chci spustit na pocitaci vzdaleny.pocitac aplikaci tak, aby se zobrazila na X serveru pocitace, ze ktereho jsem inicializoval spojeni (domaci.pocitac).

V /etc/ssh/sshd_config mam radku

X11Forwarding yes

Na pocitaci domaci.pocitac bezej X, napisu

ssh -X vzdaleny.pocitac

Potom napisu

echo $DISPLAY

a vysledkem je prazdna radka :(

Uz se to tu nekolikrat resilo, ale vetsinou tazateli pomohlo povolit ten forwarding, u me to ale stale nechodi.

PS: Distribuce Slackware 9.1

Odpovědi

[Hynek (Pichi) Vychodil]

X forwarding musí být povolený i na straně sshd (serveru).

[asym]

Jak to povolit? Nejsem tam root.

[asym]

Serverem myslite to co jsem oznacil jako vzdaleny.pocitac, tedy vlastne X klient?

[Hynek (Pichi) Vychodil]

Ano serverem myslím ten počítač na kterém běží serverový daemon ssh a po kterém chcete, aby vám přesměroval požadavky na něm spouštěných X clientů na lokální socket na váš lokální X server. Pokud tam nejste root, tak zkuste požádat tamního roota, aby to povolil. Jinak se to dá vyřešit ručně, což ale není triviální.

[Ondřej Kubečka]

A neprepisuje vam to hodnutu promenne DISPLAY nekde v nejakem startovacim skriptu/profilu? Zkuste ji pripadne zadat rucne, obvykle je to localhost:10 pro displej :0 na vzdalene masine (ten Offset se da nastivt, ale tusim, ze 10 je vychozi hodnota, pokud jste to nemenil)...

[asym]

$ export DISPLAY=ip.domaciho.pocitace:10
$ xclock &
[1] 554
$ Error: Can't open display: ip.domaciho.pocitace:10

Jako IP zadavam to, co se mi vypise po konfiguraci ppp spojeni jako local IP address.

[asym]

Jo, a ofset je nastaven sshd_config na 10.

[Michal Marek (twofish)]

Má tam být localhost, od toho je to forwardování. Nicméně jestli to server nepodporuje, tak to nepůjde. Co vypisuje ssh -v -X vzdaleny.pocitac?

Přinejhorším si můžeš udělat normální tunel

ssh -R 6010:localhost:6000

a vygenerovat speciální autorizační cookie pro server (hledej xauth(1)), to by mělo být stejné jako ssh -Y.

[asym]

bash-2.05b$ ssh -X -v klastr1.icpf.cas.cz
OpenSSH_3.7.1p2, SSH protocols 1.5/2.0, OpenSSL 0.9.7b 10 Apr 2003
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to klastr1.icpf.cas.cz [147.231.137.254] port 22.
debug1: Connection established.
debug1: identity file /home/honza/.ssh/identity type -1
debug1: identity file /home/honza/.ssh/id_rsa type -1
debug1: identity file /home/honza/.ssh/id_dsa type -1
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.4p1 Debian 1:3.4p1-1.woody.3
debug1: match: OpenSSH_3.4p1 Debian 1:3.4p1-1.woody.3 pat OpenSSH_3.2*,OpenSSH_3.3*,OpenSSH_3.4*,OpenSSH_3.5*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.7.1p2
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'klastr1.icpf.cas.cz' is known and matches the RSA host key.
debug1: Found key in /home/honza/.ssh/known_hosts:4
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /home/honza/.ssh/identity
debug1: Trying private key: /home/honza/.ssh/id_rsa
debug1: Trying private key: /home/honza/.ssh/id_dsa
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: password
honza@klastr1.icpf.cas.cz's password: 
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Requesting X11 forwarding with authentication spoofing.
Linux k1 2.4.22-newk1 #1 Sat Sep 20 16:03:33 CEST 2003 i686 unknown

Last login: Wed Jun  8 21:27:23 2005 from 159.97.108.194.contactel.net

You two ought to be more careful--your love could drag on for years and years.

honza@k1:~$ export DISPLAY=localhost:10
honza@k1:~$ xclock&
[1] 589
honza@k1:~$ Error: Can't open display: localhost:10

[Hynek (Pichi) Vychodil]

Můžete ještě napsat echo $DISPLAY před spuštěním ssh, ať jsme si úplně jistí

   X11 and TCP forwarding
     If the ForwardX11 variable is set to ``yes'' (or see the description of
     the -X and -x options described later) and the user is using X11 (the
     DISPLAY environment variable is set), the connection to the X11 display
     is automatically forwarded to the remote side in such a way that any X11
     programs started from the shell (or command) will go through the
     encrypted channel, and the connection to the real X server will be made
     from the local machine.  The user should not manually set DISPLAY.  For-
     warding of X11 connections can be configured on the command line or in
     configuration files.

     The DISPLAY value set by ssh will point to the server machine, but with a
     display number greater than zero.  This is normal, and happens because
     ssh creates a ``proxy'' X server on the server machine for forwarding the
     connections over the encrypted channel.

     ssh will also automatically set up Xauthority data on the server machine.
     For this purpose, it will generate a random authorization cookie, store
     it in Xauthority on the server, and verify that any forwarded connections
     carry this cookie and replace it by the real cookie when the connection
     is opened.  The real authentication cookie is never sent to the server
     machine (and no cookies are sent in the plain).

[asym]

$ echo $DISPLAY
:0.0

Nicmene ted jsem si precetl /etc/ssh/sshd_config na klastru a forwardovani neni povoleno, takze se obratim na tamniho roota, i kdyz si myslim, ze to zalezi jen na tom, co mam v configu na strane X serveru, ale uvidime. Kazdopadne zatim dik vsem.

[Zdeněk Burda]

i kdyz si myslim, ze to zalezi jen na tom, co mam v configu na strane X serveru, ale uvidime.

Pokud chceš tunelovat Xka pomocí ssh -X, tak musíš nastavit i SSH server. Už to tu pichi psal.

[asym]

Obcas plkam, sorry. Uz jsem napsal rootovi, uvidime :)

[Michal Marek (twofish)]

Sakra, on se ten výpis nemění, ať to server povolí nebo ne A /etc/sshd_config na serveru si asi ani nepřečteš...

[asym]

Uz to chodi! Je to sila, sice to po modemu nejni zrovna nejrychlejsi, ale je to lepsi nez stahovat megovej soubor s datama pro gnuplot

Diky vsem

[Hynek (Pichi) Vychodil]

Ech, ty jsi to potřeboval na gnuplot. To bych se víc snažil

[asym]

xclock spoustim radsi lokalne