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

• Previous message: all mail refused: "Re: How to prevent or quickly fix hosed ssh tunnels"
• In reply to: Dan Stromberg: "Re: What's the deal on the -X vs -Y thing?"
• Next in thread: Dan Stromberg: "Re: What's the deal on the -X vs -Y thing?"
• Reply: Dan Stromberg: "Re: What's the deal on the -X vs -Y thing?"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

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.

• Previous message: all mail refused: "Re: How to prevent or quickly fix hosed ssh tunnels"
• In reply to: Dan Stromberg: "Re: What's the deal on the -X vs -Y thing?"
• Next in thread: Dan Stromberg: "Re: What's the deal on the -X vs -Y thing?"
• Reply: Dan Stromberg: "Re: What's the deal on the -X vs -Y thing?"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]