X11 display forwarding - SSH

This is a discussion on X11 display forwarding - SSH ; Howdy, I'm having a bit of trouble with X11 display forwarding. This started when I upgraded to OpenSSH 4.3p1. I've read the FAQ and I know about the usual problem when upgrading involving ForwardX11Trusted. This is how I have my ...

+ Reply to Thread
Results 1 to 13 of 13

Thread: X11 display forwarding

  1. X11 display forwarding

    Howdy,

    I'm having a bit of trouble with X11 display forwarding. This started
    when I upgraded to OpenSSH 4.3p1. I've read the FAQ and I know about
    the usual problem when upgrading involving ForwardX11Trusted. This is
    how I have my config's set:

    /etc/ssh/ssh_config: ForwardAgent yes
    /etc/ssh/ssh_config: ForwardX11 yes
    /etc/ssh/ssh_config: ForwardX11Trusted yes

    /etc/ssh/sshd_config: X11Forwarding yes
    /etc/ssh/sshd_config: X11UseLocalhost no

    The error message I get is:

    X11 connection rejected because of wrong authentication.
    X connection to myfirewall.mydom.com:11.1 broken \
    (explicit kill or server shutdown).

    I launch apps in one of two ways.

    ssh myfirewall.mydom.com -f 'ssh otherhost.mydom.com xterm'

    or

    ssh myfirewall.mydom.com -f xterm

    After some trial and error I observed that the above commands
    sometimes work and sometimes don't. It certainly involves
    xauth stuff. At one point I killed my X servers, zeroed out
    my .Xauthority files, and restarted the X servers. That move
    got rid of a problem where I couldn't start new xterms from an
    already connected remote xterm. Now once I've got a remote xterm
    open, I can open other apps from within it.

    I've noticed that my first remote application runs in DISPLAY
    :10.1 (two headed display running the local command from :0.1)
    and that makes sense to me. I've also noticed that sometimes
    subsequent local commands will try to run remote applications
    in DISPLAY :11.1. Before restarting my X servers, every new
    application would increment the X display and I'd run into my
    firewall restriction having only 10 ports open for X forwarding.
    I haven't been able to completely describe to myself when or how
    the DISPLAY will increment.

    When I inspect my xauth stuff in a working condition I see this.

    ===============

    otherhost.mydom.com DISPLAY is otherhost.mydom.com:10.1

    otherhost.mydom.com xauth list says

    otherhost.mydom.com:10 MIT-MAGIC-COOKIE-1 597d13f5b61fd07b79c6d4e5942fd553
    otherhost.mydom.com:10 MIT-MAGIC-COOKIE-1 afe3fd4603519360202ecbcc2ca02338
    otherhost.mydom.com:11 MIT-MAGIC-COOKIE-1 3f0946d4fbcca2f7d08eb4befcef82d5
    otherhost.mydom.com:11 MIT-MAGIC-COOKIE-1 6d3967fd9fd59df30250fc9ca38449a1
    myfirewall.mydom.com:10 MIT-MAGIC-COOKIE-1 ee1623a886120aa4fcf708c814f6b793

    ===============

    myfirewall.mydom.com isn't running displayed app's now. DISPLAY isn't set.

    myfirewall.mydom.com xauth list says

    myfirewall.mydom.com:10 MIT-MAGIC-COOKIE-1 909822c0778498c82f3b64886ed6ceed
    myfirewall.mydom.com:11 MIT-MAGIC-COOKIE-1 a87659f3c8a1d4d4eaae2effdeb29d46

    ===============

    local host (where I start everything) xauth list says

    lwe125529.cse.tek.com:10 MIT-MAGIC-COOKIE-1 6543aba06e20e269e135158af740b2bf

    ===============


    Now that just doesn't make any sense! Shouldn't my at least a
    pair of my MIT-MAGIC-COOKIEs match? That would seem to be why I
    can't start a new application now from my local host. But, how
    in the world did the applications currently open start? And,
    why can I start a new xterm from my xterm currently running on
    otherhost.mydom.com when no xauth cookies would seem to permit
    that?

    For what it's worth, all this worked just fine with OpenSSH
    3.7.1p2 for a long time. This also worked with OpenSSH 4.3p1 for
    about a week, which *might* have been how long it was until I
    finally rebooted myfirewall.mydom.com.

    I'm really confused. Anyone got any ideas to start my sorting
    this out?

    Thanks....

    --
    PLEASE post a SUMMARY of the answer(s) to your question(s)!
    Show Windows & Gates to the exit door.
    Unless otherwise noted, the statements herein reflect my personal
    opinions and not those of any organization with which I may be affiliated.

  2. Re: X11 display forwarding

    Kevin the Drummer wrote:
    > Howdy,
    >
    > I'm having a bit of trouble with X11 display forwarding. This started
    > when I upgraded to OpenSSH 4.3p1. I've read the FAQ and I know about
    > the usual problem when upgrading involving ForwardX11Trusted. This is
    > how I have my config's set:
    >
    > /etc/ssh/ssh_config: ForwardAgent yes
    > /etc/ssh/ssh_config: ForwardX11 yes
    > /etc/ssh/ssh_config: ForwardX11Trusted yes
    >
    > /etc/ssh/sshd_config: X11Forwarding yes
    > /etc/ssh/sshd_config: X11UseLocalhost no
    >
    > The error message I get is:
    >
    > X11 connection rejected because of wrong authentication.
    > X connection to myfirewall.mydom.com:11.1 broken \
    > (explicit kill or server shutdown).
    >
    > I launch apps in one of two ways.
    >
    > ssh myfirewall.mydom.com -f 'ssh otherhost.mydom.com xterm'
    >
    > or
    >
    > ssh myfirewall.mydom.com -f xterm
    >
    > After some trial and error I observed that the above commands
    > sometimes work and sometimes don't. It certainly involves
    > xauth stuff. At one point I killed my X servers, zeroed out
    > my .Xauthority files, and restarted the X servers. That move
    > got rid of a problem where I couldn't start new xterms from an
    > already connected remote xterm. Now once I've got a remote xterm
    > open, I can open other apps from within it.
    >
    > I've noticed that my first remote application runs in DISPLAY
    > :10.1 (two headed display running the local command from :0.1)
    > and that makes sense to me. I've also noticed that sometimes
    > subsequent local commands will try to run remote applications
    > in DISPLAY :11.1. Before restarting my X servers, every new
    > application would increment the X display and I'd run into my
    > firewall restriction having only 10 ports open for X forwarding.
    > I haven't been able to completely describe to myself when or how
    > the DISPLAY will increment.
    >
    > When I inspect my xauth stuff in a working condition I see this.
    >
    > ===============
    >
    > otherhost.mydom.com DISPLAY is otherhost.mydom.com:10.1
    >
    > otherhost.mydom.com xauth list says
    >
    > otherhost.mydom.com:10 MIT-MAGIC-COOKIE-1 597d13f5b61fd07b79c6d4e5942fd553
    > otherhost.mydom.com:10 MIT-MAGIC-COOKIE-1 afe3fd4603519360202ecbcc2ca02338
    > otherhost.mydom.com:11 MIT-MAGIC-COOKIE-1 3f0946d4fbcca2f7d08eb4befcef82d5
    > otherhost.mydom.com:11 MIT-MAGIC-COOKIE-1 6d3967fd9fd59df30250fc9ca38449a1
    > myfirewall.mydom.com:10 MIT-MAGIC-COOKIE-1 ee1623a886120aa4fcf708c814f6b793
    >
    > ===============
    >
    > myfirewall.mydom.com isn't running displayed app's now. DISPLAY isn't set.
    >
    > myfirewall.mydom.com xauth list says
    >
    > myfirewall.mydom.com:10 MIT-MAGIC-COOKIE-1 909822c0778498c82f3b64886ed6ceed
    > myfirewall.mydom.com:11 MIT-MAGIC-COOKIE-1 a87659f3c8a1d4d4eaae2effdeb29d46
    >
    > ===============
    >
    > local host (where I start everything) xauth list says
    >
    > lwe125529.cse.tek.com:10 MIT-MAGIC-COOKIE-1 6543aba06e20e269e135158af740b2bf
    >
    > ===============
    >
    >
    > Now that just doesn't make any sense! Shouldn't my at least a
    > pair of my MIT-MAGIC-COOKIEs match? That would seem to be why I
    > can't start a new application now from my local host. But, how
    > in the world did the applications currently open start? And,
    > why can I start a new xterm from my xterm currently running on
    > otherhost.mydom.com when no xauth cookies would seem to permit
    > that?
    >
    > For what it's worth, all this worked just fine with OpenSSH
    > 3.7.1p2 for a long time. This also worked with OpenSSH 4.3p1 for
    > about a week, which *might* have been how long it was until I
    > finally rebooted myfirewall.mydom.com.
    >
    > I'm really confused. Anyone got any ideas to start my sorting
    > this out?
    >
    > Thanks....
    >



    Try adding -X:

    ssh myfirewall.mydom.com -Xf xterm

  3. Re: X11 display forwarding

    VS wrote:
    > Try adding -X:
    > ssh myfirewall.mydom.com -Xf xterm


    I get the same error with or without the -X part.

    Thanks....


    --
    PLEASE post a SUMMARY of the answer(s) to your question(s)!
    Show Windows & Gates to the exit door.
    Unless otherwise noted, the statements herein reflect my personal
    opinions and not those of any organization with which I may be affiliated.

  4. Re: X11 display forwarding


    Chained forwarding is always a pain, for several reasons, and also less
    secure since the intermediate system is a MITM. You'll usually do better
    with a direct SSH session. If you have something like netcat (nc) on the
    firewall, then try this:

    ssh -X -o proxycommand="ssh -qax myfirewall.mydom.com nc %h %p" otherhost.mydom.com

    --
    Richard Silverman
    res@qoxp.net


  5. Re: X11 display forwarding

    On 2006-04-06, Kevin the Drummer wrote:
    > I'm having a bit of trouble with X11 display forwarding. This started
    > when I upgraded to OpenSSH 4.3p1. I've read the FAQ and I know about
    > the usual problem when upgrading involving ForwardX11Trusted. This is
    > how I have my config's set:
    >
    > /etc/ssh/ssh_config: ForwardAgent yes
    > /etc/ssh/ssh_config: ForwardX11 yes
    > /etc/ssh/ssh_config: ForwardX11Trusted yes
    >
    > /etc/ssh/sshd_config: X11Forwarding yes
    > /etc/ssh/sshd_config: X11UseLocalhost no


    Change X11UseLocalhost to "yes" and it will probably work.

    > After some trial and error I observed that the above commands
    > sometimes work and sometimes don't. It certainly involves
    > xauth stuff.


    Wild guess: the firewall's hostname resolves to two or more IP addresses?

    --
    Darren Tucker (dtucker at zip.com.au)
    GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
    usually comes from bad judgement.

  6. Re: X11 display forwarding

    Darren Tucker wrote:
    > On 2006-04-06, Kevin the Drummer wrote:
    > > I'm having a bit of trouble with X11 display forwarding. This started
    > > when I upgraded to OpenSSH 4.3p1. I've read the FAQ and I know about
    > > the usual problem when upgrading involving ForwardX11Trusted. This is
    > > how I have my config's set:
    > >
    > > /etc/ssh/ssh_config: ForwardAgent yes
    > > /etc/ssh/ssh_config: ForwardX11 yes
    > > /etc/ssh/ssh_config: ForwardX11Trusted yes
    > >
    > > /etc/ssh/sshd_config: X11Forwarding yes
    > > /etc/ssh/sshd_config: X11UseLocalhost no

    >
    > Change X11UseLocalhost to "yes" and it will probably work.


    This seems counterintuitive. Why should that work? Sorry to be dense
    about this. On which host should I change to "yes"? The firewall host?
    The remote client host? The local host, the one that initiates the ssh
    commands?

    > > After some trial and error I observed that the above commands
    > > sometimes work and sometimes don't. It certainly involves
    > > xauth stuff.

    >
    > Wild guess: the firewall's hostname resolves to two or more IP addresses?


    Yes. The firewall is my VPN host. As such, it resolves to the VPN
    client address as known by the company end, and it resolves to a
    192.168.1.X number, as known by the home network.

    Thanks....

    --
    PLEASE post a SUMMARY of the answer(s) to your question(s)!
    Show Windows & Gates to the exit door.
    Unless otherwise noted, the statements herein reflect my personal
    opinions and not those of any organization with which I may be affiliated.

  7. Re: X11 display forwarding

    Richard E. Silverman wrote:
    > Chained forwarding is always a pain, for several reasons,


    Could you help me to understant those reasons please?

    I wonder why this worked very well for a long time before I upgraded
    from OpenSSH 3.7.1p2 to OpenSSH 4.3p1? It also worked flawlessly for
    almost 2 weeks with 4.3p1. I think it was around the time that I
    rebooted the firewall machine that I started having troubles.

    > and also less
    > secure since the intermediate system is a MITM.


    I've got hostkey checking and other parameters set to try and avoid the
    obvious exploits.

    > You'll usually do better
    > with a direct SSH session. If you have something like netcat (nc) on the
    > firewall, then try this:
    >
    > ssh -X -o proxycommand="ssh -qax myfirewall.mydom.com nc %h %p" \
    > otherhost.mydom.com


    OK, that worked. Why, might I ask, did that work?

    I see this with 'rpm -qi nc' on my system:

    netcat has been compiled with -DGAPING_SECURITY_HOLE turned
    on. I do not believe this is as much of a security hole as
    the author makes it out to be, *if* you know what you're
    doing (but then, if you didn't, you'd still be using telnet
    ;-)). Since the spawned program will run as whatever user
    started netcat, don't use -e as root.

    It seems that I might want to recompile netcat.

    Thanks...

    --
    PLEASE post a SUMMARY of the answer(s) to your question(s)!
    Show Windows & Gates to the exit door.
    Unless otherwise noted, the statements herein reflect my personal
    opinions and not those of any organization with which I may be affiliated.

  8. Re: X11 display forwarding

    >>>>> "KDKevin" == Kevin the Drummer writes:

    KDKevin> Richard E. Silverman wrote:
    >> Chained forwarding is always a pain, for several reasons,


    KDKevin> Could you help me to understant those reasons please?

    The forwarded stream goes through several TCP connections, presenting
    multiple places where it can go wrong: xauth glitches with X forwarding,
    ports left in TIME_WAIT due to previous aborted connections, binding of
    wrong address, etc. You have to choose ephemeral ports for the
    forwardings and communicate them to the various SSH clients and servers
    involved. Also, the end client does not have the chance to verify the end
    server's identity, since the client is only talking to the next host in
    the chain -- and even that checking is awkward, because the client will
    see a different hostkey than it's expecting: that of the next host in the
    chain rather than the listening host in the first forwarding.

    >> and also less secure since the intermediate system is a MITM.


    KDKevin> I've got hostkey checking and other parameters set to try and
    KDKevin> avoid the obvious exploits.

    That doesn't matter. The point I was making is that, with chaining, your
    data exists in plaintext on the intermediate hosts as it passes from one
    SSH connection to the next. If one of those hosts is compromised, so is
    your data.

    >> You'll usually do better with a direct SSH session. If you have
    >> something like netcat (nc) on the firewall, then try this:
    >>
    >> ssh -X -o proxycommand="ssh -qax myfirewall.mydom.com nc %h %p" \
    >> otherhost.mydom.com


    KDKevin> OK, that worked. Why, might I ask, did that work?

    ProxyCommand gives an arbitrary method to establish a connection between
    the client and server. In this case we are using ssh yet again, but
    that's not germane; it could have been rsh for all we care, or a serial
    line. This allows the client to talk directly to the end server,
    simplifying everything.

    KDKevin> I see this with 'rpm -qi nc' on my system:

    KDKevin> netcat has been compiled with -DGAPING_SECURITY_HOLE
    KDKevin> turned on. I do not believe this is as much of a security
    KDKevin> hole as the author makes it out to be, *if* you know what
    KDKevin> you're doing (but then, if you didn't, you'd still be using
    KDKevin> telnet ;-)). Since the spawned program will run as whatever
    KDKevin> user started netcat, don't use -e as root.

    KDKevin> It seems that I might want to recompile netcat.

    Perhaps, but it's not relevant to this situation since you're not using
    that feature.

    --
    Richard Silverman
    res@qoxp.net


  9. Re: X11 display forwarding

    On 2006-04-10, Kevin the Drummer wrote:
    > Darren Tucker wrote:
    >> On 2006-04-06, Kevin the Drummer wrote:
    >> > I'm having a bit of trouble with X11 display forwarding. This started
    >> > when I upgraded to OpenSSH 4.3p1. I've read the FAQ and I know about
    >> > the usual problem when upgrading involving ForwardX11Trusted. This is
    >> > how I have my config's set:
    >> >
    >> > /etc/ssh/ssh_config: ForwardAgent yes
    >> > /etc/ssh/ssh_config: ForwardX11 yes
    >> > /etc/ssh/ssh_config: ForwardX11Trusted yes
    >> >
    >> > /etc/ssh/sshd_config: X11Forwarding yes
    >> > /etc/ssh/sshd_config: X11UseLocalhost no

    >>
    >> Change X11UseLocalhost to "yes" and it will probably work.

    >
    > This seems counterintuitive. Why should that work?


    I suspect your problem stems from the fact that your hostname resolves
    to more than one IP address, and xauth and sshd end up disagreeing
    about which should be used. This probably won't be the case with
    "localhost", and as long as you're using only ssh to make the next hop
    (as opposed to pointing $DISPLAY at the firewall and munging xauth
    yourself) it should still work.

    Richard's solution is nicer, though.

    > Sorry to be dense
    > about this. On which host should I change to "yes"? The firewall host?
    > The remote client host? The local host, the one that initiates the ssh
    > commands?


    The firewall.

    >> Wild guess: the firewall's hostname resolves to two or more IP addresses?

    >
    > Yes. The firewall is my VPN host. As such, it resolves to the VPN
    > client address as known by the company end, and it resolves to a
    > 192.168.1.X number, as known by the home network.


    Your reboot when the problems first started occuring didn't happen to
    correspond to a change in hostname, name resolution (/etc/hosts or
    DNS) or a change in system libraries?

    --
    Darren Tucker (dtucker at zip.com.au)
    GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
    usually comes from bad judgement.

  10. Re: X11 display forwarding

    Darren Tucker wrote:
    > Your reboot [1-2 weeks after upgrading from OpenSSH 3.7.1p2 to
    > OpenSSH 4.3p1] when the problems first started occuring didn't
    > happen to correspond to a change in hostname, name resolution
    > (/etc/hosts or DNS) or a change in system libraries?


    The only library that changed was openssl, because upgrading
    openssh required that.

    Thanks...

    --
    PLEASE post a SUMMARY of the answer(s) to your question(s)!
    Show Windows & Gates to the exit door.
    Unless otherwise noted, the statements herein reflect my personal
    opinions and not those of any organization with which I may be affiliated.

  11. Re: X11 display forwarding

    On Fri, 07 Apr 2006 14:10:41 -0400, Richard E. Silverman wrote:
    > Chained forwarding is always a pain, for several reasons, and also
    > less secure since the intermediate system is a MITM. You'll usually
    > do better with a direct SSH session. If you have something like
    > netcat (nc) on the firewall, then try this:
    >
    > ssh -X -o proxycommand="ssh -qax myfirewall.mydom.com nc %h %p"
    > otherhost.mydom.com


    Richard, over the years I have gleaned some tremendous ssh tips from
    your posts here. Now thanks for the one above, it works a treat for my
    situation and is neater than the more awkward piggyback I have been
    using till now.

    Thanks again.


  12. Re: X11 display forwarding

    >>>>> "mark" == mark writes:

    mark> On Fri, 07 Apr 2006 14:10:41 -0400, Richard E. Silverman wrote:
    >> Chained forwarding is always a pain, for several reasons, and also
    >> less secure since the intermediate system is a MITM. You'll
    >> usually do better with a direct SSH session. If you have something
    >> like netcat (nc) on the firewall, then try this:
    >>
    >> ssh -X -o proxycommand="ssh -qax myfirewall.mydom.com nc %h %p"
    >> otherhost.mydom.com


    mark> Richard, over the years I have gleaned some tremendous ssh tips
    mark> from your posts here. Now thanks for the one above, it works a
    mark> treat for my situation and is neater than the more awkward
    mark> piggyback I have been using till now.

    You're quite welcome!

    --
    Richard Silverman
    res@qoxp.net


  13. SOLVED -- Re: X11 display forwarding

    Kevin the Drummer wrote:
    > I'm having a bit of trouble with X11 display forwarding. This started
    > when I upgraded to OpenSSH 4.3p1. I've read the FAQ and I know about
    > the usual problem when upgrading involving ForwardX11Trusted. This is
    > how I have my config's set:
    >
    > /etc/ssh/ssh_config: ForwardAgent yes
    > /etc/ssh/ssh_config: ForwardX11 yes
    > /etc/ssh/ssh_config: ForwardX11Trusted yes
    >
    > /etc/ssh/sshd_config: X11Forwarding yes
    > /etc/ssh/sshd_config: X11UseLocalhost no
    >
    > The error message I get is:
    >
    > X11 connection rejected because of wrong authentication.
    > X connection to myfirewall.mydom.com:11.1 broken \
    > (explicit kill or server shutdown).
    >
    > I launch apps in one of two ways.
    >
    > ssh myfirewall.mydom.com -f 'ssh otherhost.mydom.com xterm'
    >
    > or
    >
    > ssh myfirewall.mydom.com -f xterm

    [snip]
    > For what it's worth, all this worked just fine with OpenSSH
    > 3.7.1p2 for a long time. This also worked with OpenSSH 4.3p1 for
    > about a week, which *might* have been how long it was until I
    > finally rebooted myfirewall.mydom.com.


    I found the problem. I'm not sure why this is, but I now need to
    set "X11UseLocalhost yes" in sshd_config. A *long* time ago I
    got used to setting this to "no", otherwise X forwarding wouldn't
    work. Now for the first time I'm required to set it to "yes".
    I found the answer by trial and error with all of the relevant
    parameters in sshd_config. Everything seems to be working again,
    including stuff like this:

    ssh myfirewall.mydom.com -f 'ssh otherhost.mydom.com xterm'

    I hope this helps someone....
    --
    PLEASE post a SUMMARY of the answer(s) to your question(s)!
    Show Windows & Gates to the exit door.
    Unless otherwise noted, the statements herein reflect my personal
    opinions and not those of any organization with which I may be affiliated.

+ Reply to Thread