Problems with SSH and X11

[Mariano Kamp]

Hi,

I have two boxes, one with X (black) and one without (rock). I want to run
an X Application on rock, but always get the message that it is not possible
to connect to the remote xserver.

What I do is the following:

***@black:~$ ssh -X rock
The authenticity of host 'rock (192.168.0.1)' can't be established.
***@rock's password:
Linux rock 2.4.18-bf2.4 #1 Son Apr 14 09:53:28 CEST 2002 i686 GNU/Linux
[..] abbreviated
***@rock:~$ echo $DISPLAY
[ void - just one blank line ]

From what I got from my googling. The DISPLAY variable should have been set,
shouldn't it? At least I am sure I read that one shouldn't set it by hand...

***@rock:~$ xterm
xterm Xt error: Can't open display:

Hmmh?!

***@rock:~$ DISPLAY=black:0.0 xterm
Xlib: connection to "black:0.0" refused by server
Xlib: No protocol specified

xterm Xt error: Can't open display: black:0.0
So, my X-Server on black is refusing to talk ....

On black kdm.log says this:
AUDIT: Sat Sep 6 17:15:28 2003: 304 X: client 20 rejected from IP 192.168.0.1
port 32794

192.168.0.1 is the ip of rock.

If I run xterm locally, but with explicit IP it works:
***@black:~$ DISPLAY=black:0.0 xterm

Besides that I have another thing with SSH bugging me. Maybe these issues
are related?
When I try to copy something with scp from rock to black, like this:

***@rock:~$ scp foo ***@black:.
***@black's password:
executing /etc/bash.bashrc
***@rock:~$

I just get the message that /etc/bash.bashrc has been executed, which is just
some debug message for me that this file bas been executed on rock.

Btw. I am running unstable.

I am also wondering why I have ssh and ssh2 on my machine. Can I remove one
of them? How? apt-get remove ssh?

I am a bit lost and don't understand it. Any ideas?

Cheers,
Mariano

[Colin Watson]

Post by Mariano Kamp
The authenticity of host 'rock (192.168.0.1)' can't be established.
Linux rock 2.4.18-bf2.4 #1 Son Apr 14 09:53:28 CEST 2002 i686 GNU/Linux
[..] abbreviated
[ void - just one blank line ]

I bet you don't have xbase-clients installed on the remote system.

Post by Mariano Kamp
Besides that I have another thing with SSH bugging me. Maybe these issues
are related?

No, they aren't.

Post by Mariano Kamp
executing /etc/bash.bashrc
I just get the message that /etc/bash.bashrc has been executed, which is just
some debug message for me that this file bas been executed on rock.

You shouldn't do it like that. This is a common mistake, but it breaks
the scp protocol. Guard the debug message such that it only gets
displayed for interactive shells, something like this:

case $- in
*i*)
echo 'executing /etc/bash.bashrc'
# other interactive stuff goes here, if you want
;;
esac

Post by Mariano Kamp
I am also wondering why I have ssh and ssh2 on my machine.

You installed them both, probably. ;)

Post by Mariano Kamp
Can I remove one of them? How? apt-get remove ssh?

ssh2 wasn't properly maintained for a long time, is non-free, and has
been removed from Debian. 'dpkg --purge ssh2' is probably what you want.

Cheers,

[Mariano Kamp]

Hi Colin, Ismael,

thanks very much for the help ... I can see progress now.

Post by Colin Watson
I bet you don't have xbase-clients installed on the remote system.

Yeah, the settings of the DISPLAY variable works fine now.

rock:~# xterm
Xlib: connection to "localhost:10.0" refused by server
Xlib: Invalid MIT-MAGIC-COOKIE-1 key
Warning: This program is an suid-root program or is being run by the root
user.
The full text of the error or warning message cannot be safely formatted
in this environment. You may get a more descriptive message by running the
program as a non-root user or by removing the suid bit on the executable.
xterm Xt error: Can't open display: %s
rock:~#

But the login still doesn't work. Somehow the xserver on black is rejecting my
requests.

AUDIT: Sat Sep 6 18:35:04 2003: 304 X: client 23 rejected from local host
Auth name: MIT-MAGIC-COOKIE-1 ID: -1

Post by Colin Watson
You shouldn't do it like that. This is a common mistake, but it breaks
the scp protocol. Guard the debug message such that it only gets

Right. Changed that and it's all working fine now. Thanx again.

Cheers,
Mariano

[Ismael Valladolid Torres]

Post by Mariano Kamp
I have two boxes, one with X (black) and one without (rock). I want to run
an X Application on rock, but always get the message that it is not possible
to connect to the remote xserver.

With security in mind, X11 forwarding is disabled by default on the
Debian stock sshd. Set "X11Forwarding yes" on your
/etc/ssh/sshd_config and restart the server.

# /etc/init.d/ssh restart

Regards, Ismael

[Mariano Kamp]

Hi Christophe,

thanks for taking the time.

I double checked the syntax with the man pages and I believe I already set
it up this way ... with no success.

black:/etc/ssh# grep orward *
ssh_config: ForwardAgent yes
ssh_config: ForwardX11 yes
sshd_config:X11Forwarding yes

rock:/etc/ssh# grep orward * | grep -v '#'
ssh_config:ForwardX11 yes
ssh_config:ForwardAgent yes
sshd_config:X11Forwarding yes

And the result is still the same?!

black:/etc/ssh# ssh -X ***@rock
***@rock's password:
Linux rock 2.4.18-bf2.4 #1 Son Apr 14 09:53:28 CEST 2002 i686 GNU/Linux

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sat Sep 6 18:17:49 2003 from black
rock:~# echo $DISPLAY

rock:~#

Do you know what part SSH2 plays here? I am always doing the config changes
in /etc/ssh not in /etc/ssh2.

Cheers,
Mariano

Post by Mariano Kamp
I have two boxes, one with X (black) and one without (rock). I want
to run an X Application on rock, but always get the message that it is
not possible to connect to the remote xserver.

- set "X11Forwarding" to "true" in sshd_config on the server, AND in
ssh_config on the client,
- after a ssh login, $DISPLAY was localhost:10.0 (!)
- and that's all !

[Mariano Kamp]

Silly me. After running xhost .. even those last problems vanished...

Post by Mariano Kamp
Hi Christophe,
thanks for taking the time.
I double checked the syntax with the man pages and I believe I already
set it up this way ... with no success.
black:/etc/ssh# grep orward *
ssh_config: ForwardAgent yes
ssh_config: ForwardX11 yes
sshd_config:X11Forwarding yes
rock:/etc/ssh# grep orward * | grep -v '#'
ssh_config:ForwardX11 yes
ssh_config:ForwardAgent yes
sshd_config:X11Forwarding yes
And the result is still the same?!
Linux rock 2.4.18-bf2.4 #1 Son Apr 14 09:53:28 CEST 2002 i686 GNU/Linux
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sat Sep 6 18:17:49 2003 from black
rock:~# echo $DISPLAY
rock:~#
Do you know what part SSH2 plays here? I am always doing the config
changes in /etc/ssh not in /etc/ssh2.
Cheers,
Mariano

Post by Mariano Kamp
I have two boxes, one with X (black) and one without (rock). I want
to run an X Application on rock, but always get the message that it is
not possible to connect to the remote xserver.

- set "X11Forwarding" to "true" in sshd_config on the server, AND in
ssh_config on the client,
- after a ssh login, $DISPLAY was localhost:10.0 (!)
- and that's all !

[Paul Johnson]

Post by Mariano Kamp
Silly me. After running xhost .. even those last problems vanished...

xhost is great...if you don't mind anybody else being able to read
your screen and what you're typing remotely without your knowledge.

- --
.''`. Paul Johnson <***@ursine.ca>
: :' :
`. `'` proud Debian admin and user
`- Debian - when you have better things to do than fix a system

[Mariano Kamp]

Paul,

I am behind a firewall. That should be ok then, shouldn't it?

Anyway, would there be any other way to enable one box to use of X from
another box?

Cheers,
Mariano

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Mariano Kamp
Silly me. After running xhost .. even those last problems vanished...

xhost is great...if you don't mind anybody else being able to read
your screen and what you're typing remotely without your knowledge.
- --
`. `'` proud Debian admin and user
`- Debian - when you have better things to do than fix a system
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQE/W2RRUzgNqloQMwcRAplmAKCUdzV2kRysndCwTNytww7Vr3xVJwCgk917
w19E4ttPBnjg/NBCUPs1Oq8=
=312Q
-----END PGP SIGNATURE-----

[Jacob Anawalt]

Post by Mariano Kamp

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Mariano Kamp
Silly me. After running xhost .. even those last problems vanished...

xhost is great...if you don't mind anybody else being able to read
your screen and what you're typing remotely without your knowledge.

I am behind a firewall. That should be ok then, shouldn't it?
Anyway, would there be any other way to enable one box to use of X from
another box?

I'll leave the "Is xhost <some option> ok here" question for others to
discuss in depth, and just address the second half of your question.

When you ssh with X11 forwarding, and the remote system at least has
xbase-clients installed (the local would have a full X11 system) there
should not be a need to use xhost. I haven't had to use the xhost
command since I started using ssh.

The X11 session data should be carried across the ssh tunnel instead of
going unencrypted outside of the ssh tunnel between the two systems. If
your $DISPLAY environment variable for your xterminal ssh session to
rock is set to black:display[.screen] (ie black:10.0), then you would
have to type "xhost +" or "xhost +rock" on black to get your X11 apps to
appear on rock and the data is not being forwarded over ssh.

Now that you've made the changes Collin suggested, when you ssh -X from
black to rock, "echo $DISPLAY" should return localhost:display[.screen]
(ie localhost:10.0) and not black:display[.screen]. It should
automatically get set to localhost:display[.screen] as you connect. If
it isn't being set to localhost:display[.screen] and you connected with
"ssh -X rock" then something else is wrong. Maybe you haven't restarted
the ssh daemon on black since you set "ForwardX11 yes" in the
sshd_config file?


Jacob
P.s. The suggested format for posting on this list is to post your
response at the bottom.

[Mariano Kamp]

Jacob,

thanks for your detailed answer - it works now.

Post by Jacob Anawalt
When you ssh with X11 forwarding, and the remote system at least has
xbase-clients installed (the local would have a full X11 system) there
should not be a need to use xhost. I haven't had to use the xhost
command since I started using ssh.
The X11 session data should be carried across the ssh tunnel instead of
going unencrypted outside of the ssh tunnel between the two systems. If
your $DISPLAY environment variable for your xterminal ssh session to
rock is set to black:display[.screen] (ie black:10.0), then you would
have to type "xhost +" or "xhost +rock" on black to get your X11 apps to
appear on rock and the data is not being forwarded over ssh.
Now that you've made the changes Collin suggested, when you ssh -X from
black to rock, "echo $DISPLAY" should return localhost:display[.screen]
(ie localhost:10.0) and not black:display[.screen]. It should
automatically get set to localhost:display[.screen] as you connect. If
it isn't being set to localhost:display[.screen] and you connected with
"ssh -X rock" then something else is wrong. Maybe you haven't restarted
the ssh daemon on black since you set "ForwardX11 yes" in the
sshd_config file?

<restarted sshd>
***@black:~/.kde$ xhost -
access control enabled, only authorized clients can connect
***@black:~/.kde$ ssh -X ***@rock
***@rock's password:
[ abbreviated ... banner / last login ]
rock:~# echo $DISPLAY
localhost:10.0
rock:~# xterm
< works fine.... I feel much more save now ;-)>

I guess you were right about restarting the sshd ...
Again, thanks for the help to anyone participating.

Post by Jacob Anawalt
P.s. The suggested format for posting on this list is to post your
response at the bottom.

Ok, will obey.

Cheers,
Mariano

[Ismael Valladolid Torres]

Post by Mariano Kamp
I am behind a firewall. That should be ok then, shouldn't it?

I find ssh lovely for tunneling almost every service across a firewall
where only the port for the ssh server is open. Even better with
compression enabled on slow links.

Regards, Ismael

[Paul Johnson]

Post by Mariano Kamp
I have two boxes, one with X (black) and one without (rock). I want to run
an X Application on rock, but always get the message that it is not possible
to connect to the remote xserver.

Gotta have X on both. ssh -C -X only works on X displays.

- --
.''`. Paul Johnson <***@ursine.ca>
: :' :
`. `'` proud Debian admin and user
`- Debian - when you have better things to do than fix a system