Portál AbcLinuxu, 13. května 2025 22:23
/etc/ssh/sshd_config mam radku
X11Forwarding yesNa pocitaci domaci.pocitac bezej X, napisu
ssh -X vzdaleny.pocitacPotom napisu
echo $DISPLAYa 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
$ export DISPLAY=ip.domaciho.pocitace:10 $ xclock & [1] 554 $ Error: Can't open display: ip.domaciho.pocitace:10Jako IP zadavam to, co se mi vypise po konfiguraci ppp spojeni jako local IP address.
ssh -R 6010:localhost:6000a vygenerovat speciální autorizační cookie pro server (hledej xauth(1)), to by mělo být stejné jako ssh -Y.
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
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).
$ echo $DISPLAY :0.0Nicmene 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.
A /etc/sshd_config na serveru si asi ani nepřečteš...
Diky vsem
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
