Re: What's the deal on the -X vs -Y thing?

From: Darren Tucker (dtucker_at_dodgy.net.au)
Date: 01/26/05

  • Next message: Neil W Rickert: "Re: What's the deal on the -X vs -Y thing?"
    Date: 26 Jan 2005 02:26:25 GMT
    
    

    In article <pan.2005.01.25.22.39.26.908259@dcs.nac.uci.edu>,
    Dan Stromberg <strombrg@dcs.nac.uci.edu> wrote:
    >>>Now try it with those lines moved to the upgraded systems' global
    >>>ssh_config (ie /usr/local/etc/ssh_config or wherever you've configured
    >>>--sysconfdir to be). This is actually what I (and the FAQ) suggested.
    >
    >This assumes centrally-maintained systems. In fact, it kind of sounds
    >like the perspective of someone who's only worked on a small number of
    >systems before. At UCI, we're herding cats.

    In a previous life I've adminned around 150 machines typically spanning
    about 3 releases of each OS. They were roughly evenly split between
    almost identical systems on the same network and disparate boxes with
    differing configs on separate networks often behind one or more firewalls.

    For the latter group of machines, about the only connectivity that you
    could be guaranteed was SSH (although sometimes you needed to "stack"
    multiple connections, eg if there was no direct route between networks).
    This is actually why I got involved with OpenSSH in the first place.

    >Believe it or not, not everyone has root access on the all the boxes they
    >work on, and not all boxes have admins who are going to realize this
    >change could help matters, nor do they have admins who would be responsive
    >to such a request - and then there are other admins with -many- more
    >useful things to do than coerce and cajole other admins into doing
    >something that they don't quite understand.

    You have admins deploying new software without testing and without being
    responsive to feedback and you're blaming the result on application
    developers?

    If you don't have root on one of these boxes you can put the entries in
    your user ~/.ssh/config, unless you also share that home dir with a
    machine with an older OpenSSH (as Per mentioned). Even then, you could
    still do something like "alias ssh='ssh -oForwardX11Trusted=yes'" or its
    equivalent in your shell.

    [..]
    >Like it or not, once lots of people start using your code, it kind of
    >takes on a life of its own. You end up with a responsibility to your
    >users not to break things without solid justification.
    >
    >And I continue to maintain that the OpenSSH team has done exactly that:
    >break things without solid justification.

    You were given a justification. If you don't agree with the change
    or that the justification is adequate then I can respect that too, even
    though I don't agree.

    >Meanwhile, I'm prototyping some workarounds in the code I've based on
    >OpenSSH, for ideas that'll get around this breakage. But it's
    >time I don't really have, that should be going into other projects!

    That's deep-ssh, right?

    As a quick fix you could use something like this as your remote ssh
    command:

    case "`ssh -V 2>&1`" in (OpenSSH_3.9*|OpenSSH_4*) ssh -Y server;; (*) ssh -X server;; esac

    Looking briefly at it, you use the least secure method of chaining ssh
    connections: if any server in the chain is compromised then the whole
    chain is compromised (eg at either the tty layer, X11 forwarding port
    or agent forwarding socket.

    I posted info about an alternative configuration in response to you a
    while back (ProxyCommand and netcat/connect).

    Ideally, I'd like to see an option for ssh that opens a connection to
    the server, starts a port forward then relays that forwarded port on
    stdin and stdout. This would remove the need for netcat or connect on
    the intermediate hosts and would allow it to work on any SSH server
    provided it allowed port forwarding and regardless of the ssh client
    (or lack thereof) on each intermediate host. (Or shell, for that matter).

    This enhanced client would only be needed on the originating host.
    The communication would be encrypted end-to-end and X11 and agent
    forwarding would not be needed on the intermediate hosts.

    -- 
    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.
    

  • Next message: Neil W Rickert: "Re: What's the deal on the -X vs -Y thing?"

    Relevant Pages

    • Re: SSH: remote login returns "invalid user"
      ... do you differentiate between client hosts and server hosts and most ... with your current account being "brownh" and you ... At present, I have three or four hosts on a LAN, and I can ssh from ...
      (Debian-User)
    • Re: Partial SNAFUs - X11Forwarding etc.
      ... to the base server machine via SSH, or it it also supposed to protect ... back "up the line" to the client machine? ... the ssh server host is compromised or otherwise untrustworthy, ... refrain from running the program via ssh X11 forwarding - there's no ...
      (comp.security.ssh)
    • Re: Openssh Port Forwarding Confusion
      ... >Now for my Port forwarding question. ... So far what I have extracted about ssh port ... You connect to a port on the SSH client. ...
      (comp.security.ssh)
    • Re: [SLE] export DISPLAY and xhost +
      ... >>impression that remote X using DISPLAY travels over ssh just because you ... > X11 and TCP forwarding ... the connection to the X11 display is auto­ ... and the connection to the real X server will be made from the ...
      (SuSE)
    • Re: ssh -X shop problem...
      ... somethings gone fubar in the X11 forwarding. ... When you "su" to gene on the X terminal, ... neither can he forward X over ssh. ... classic conditions, you'd use xhost to allow access from a remote host, ...
      (Fedora)