X client forwarding

This should be simple, but I seem to be stymied:

I have a Linux box A behind a router R with a fixed IP address.
From A I can ssh into a box B somewhere in the Internet. My question is,
How do I get X clients started on B to display on A (where an X server is
running)?

Bear in mind that there are many systems behind R, so I imagine
I'll have to do some port forwarding in R. What port(s) should I be
forwarding in R to A?

 

Use ‘ssh -X’ or turn on ForwardX11 in .ssh/config. ‘man ssh_config’ for
more details.

 

You can run the X clients over an ssh tunnel started from A.

boxA$ ssh -X boxB
boxB$ xlogo

If the -X doesn't work, try -Y instead (I can never work out which to use).

You can also run this all as one command; the -f flag tells ssh not to
block the terminal for completion but to go into the background.

boxA$ ssh -Xqf boxB /usr/bin/xlogo

Finally, if you're going to be doing this regularly, consider putting
an entry in your .ssh/config. Something like this should work:

# Settings for boxB
Host boxB boxB.example.net 10.11.12.13
Compression yes
ForwardX11 yes
ServerAliveInterval 60

# Default (at end)
Host *
Compression yes
ServerAliveInterval 60

Chris

 

Yes, and the "X11 FORWARDING" section of ssh(1) says so explicitly:

If the ForwardX11 variable is set to "yes" [...] the connection
to the X11 display is automatically forwarded to the remote side
in such a way that any X11 programs [...] will go through the
encrypted channel [...]

I.e. there is no second TCP connection being set up from B to A, and
no need to tweak the NAT box/"router".

/Jorgen

 

This is what did:

1) In .ssh/config in B I added the line

ForwardX11=yes

2) After that, in A I invoked

ssh -Y B

3) In the shell obtained in B from the ssh command in 2 I did

xterm

and I got

xterm Xt error: Can't open display: localhost:0.0

The same happens if I use ssh -X in 2, instead of ssh -Y. What am
I doing wrong?

 

Maybe ~/.ssh permissions not set correctly on either/both systems.
Maybe ~/.ssh/* permissions not set correctly on either/both systems.
Maybe ~/.ssy/known hosts is invalid.
Have you generated a key and exported it to other system?

I would
o set ~/.ssh/* 600 permissions on both nodes
o set ~/.ssh 700 permissions on both nodes
cd ~/.ssh
chmod 700 .
chmod 600 *

o remove known_hosts
rm known_hosts
cd

o generate a ssh key without a paraphrase, just hit Enter on each prompt.

ssh-keygen -t dsa

o copy it to other
ssh-copy-id -i ~/.ssh/id_dsa.pub $

o try again.
ssh $

 

They both are drwx------

They both contain a number of files, and they are all -rw-------

It does not seem to be. How would I know anyway? Would error
diagnostics be printed out at the clent side?

Yes. That is, I can ssh from A into B without having to supply a
password.

That's what I already have. Well, except for the fact that I am
using RSA keys.

Now what is the value of the DISPLAY variable supposed to be in
B, for this to work? Does it matter?

 

It should, otherwise you would not get the error.

Hopefully, $DISPLAY is not being overridden by any user executed
code, ~/.bash(whatever), /etc/profile,,,,.

Valued will depend on how many ssh process are running in target node. Example

$ echo $DISPLAY
:0

$ ssh [email protected]$(hostname --fqdn)
$ wb: echo $DISPLAY
localhost:10.0

$ ssh [email protected]$(hostname --fqdn)
$ wb: echo $DISPLAY
localhost:11.0

$ logout
Connection to WB closed.

$ echo $DISPLAY
localhost:10.0


$ logout
Connection to wb closed.

$ echo $DISPLAY
:0

 

That's a setting you should apply on A, not B.

....

That seems a bit unusual. When I do this my $DISPLAY becomes
localhost:12.0, localhost:13.0, ... i.e. ssh lets the numbering start
around 12 in order to leave room for ordinary X11 displays.

This is configured by sshd on B. How is it configured, anyway?
The server has a bunch of options related to X11 (see sshd_config(5)):

X11DisplayOffset
X11Forwarding
X11UseLocalhost
...

So it's possible for the server to refuse to do X11 forwarding.

/Jorgen

 

I have applied it on both A and B.

I have actually made sure that DISPLAY is not set in any way in B
in any of the .bash* files. The error I am getting now is

xterm Xt error: Can't open display:
xterm: DISPLAY is not set

It would seem that ssh -X or ssh -Y is not setting DISPLAY on B.

In that case I may be totally screwed for, in the situation I am
trying to sort out, I have no privileges to modify the configuration of
the SSH server in B.

 

Is $DISPLAY set on A?

 

But don't you have read access to that config? It's
/etc/ssh/sshd_config on my system, and it's world readable.

You can run ssh with the -v option to see more about what's happening,
but I'm not sure you'd see there if the server refuses to forward.
All I can see when I test is that my client /asks/ for forwarding.

/Jorgen

 

Unfortunately, not so in B. Its sysadmin seems to be quite anal
:-(

 

Yes. How is that relevant though? I just want to start an X
application in B, and have its output sent to the X server on A.

 

The ssh client on A needs to know what X server to connect to.

 

You lost me here. A connects into B by ssh. An X application is
started on B. The output from this application is to be sent to the X
server running on A. Is A connecting to any X server?

 

Yes. The communication looks, very roughly, like his:

+---------------------------+ +----------------------------+
| A | | B |
| X server <--> ssh client <----------> ssh server <--> X client |
+---------------------------+ +----------------------------+

 

This is turning out to be much more involved than I thought.
Let's see if I understand it correctly:

1) In A, for the appropriate user, in .ssh/config we must have a
line that reads

ForwardX11=yes

I don't think this is required in B, right?

2) In B, the ssh server must be configured explicitly to allow X
forwarding with

X11Forwarding yes

in /etc/ssh/sshd_config.

3) In B we must make sure that the DISPLAY environment variable
for the relevant user is not set in any way in the login scripts
(.bash_profile, .bashrc, etc.)

4) When ssh'ing from A into B we must use the -X or -Y option; it
would seem that -X does not always work.

5) In A the DISPLAY variable in the shell from which the ssh
command must be set equal to - what?

Am I still missing something here?

 

Yes, I suppose that's not the default, since there's a security
tradeoff involved.

I don't think the user's ssh config is used for anything but
/initiating/ ssh sessions. It's you @ A against sshd @ B.

As I understand it, it's normally enabled. But yeah.

Yes, but setting it manually is insane anyway -- all kinds of other
things break too if you do it, and there is no reason to do it[1].

No, 1) takes care of that. Except I cannot comment on -Y -- I have
never seen that option before, or needed it.

It's simple really: ssh cannot ask for X11 forwarding unless it's
aware of an X11 display to forward to! Also, $DISPLAY is taken care
of automatically -- if you have it, you have it for one of these
reasons:
- you're indeed running directly under X11
- you're at the far end of a tunnel already
- you've set it manually for some explicit, private reason

Possibly something related to xauth.

/Jorgen

[1] As far as I can tell. Back in the early 1990s people sometimes
did it because they were logging in via telnet or rlogin to B.

 

Yes. Setting it in those scripts would be strange anyway.

-X is equivalent to setting ForwardX11=yes. You don’t need both.

It must be set to the X display that you wish to forward. If you are
doing this from inside an xterm/gnome-terminal/etc then it should
already be set to the right thing.