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

From: Per Hedeland (per_at_hedeland.org)
Date: 01/25/05 

Date: Tue, 25 Jan 2005 07:10:56 +0000 (UTC)

In article
<41f5abc9$0$10565$5a62ac22@per-qv1-newsreader-01.iinet.net.au>
dtucker@dodgy.net.au (Darren Tucker) writes:
>In article <pan.2005.01.25.00.58.46.232107@dcs.nac.uci.edu>,
>Dan Stromberg <strombrg@dcs.nac.uci.edu> wrote:
>>I'd seen this, but I'll repeat: it's not -consistent-. Some versions of
>>ssh -require- this (or -Y), while others -choke- on it. And if you have
>>multiple versions of openssh on your systems, woe betide you if you
>>rearrange your paths for some reason - your ssh-based automation scripts
>>start breaking.
>>
>>This is going to mean a lot of retraining, recoding, and even users
>>getting frustrated and going back to xhost +. It strikes me as a
>>particularly arbitrary and capricious breakage of backward compatibility.
>
>Did you *read* the FAQ entry? It says: "The previous behaviour can be
>restored by setting ForwardX11Trusted yes in ssh_config."
>
>This means you can put something like this at the bottom of ssh_config:
>Host *
> ForwardX11Trusted yes
>
>then -X will work the way it used to in previous version. No retraining,
>no recoding, no xhost + ...

Well Darren, I generally greatly appreciate your posts, but here I have
to ask: Did you *read* what Dan wrote (already in the original post,
further spelled out above)? If it still isn't clear, maybe this helps:

$ cat .ssh/config
Host *
        ForwardX11Trusted yes
$ ssh -v somehost
OpenSSH_3.6.1p1 FreeBSD-20030924, SSH protocols 1.5/2.0, OpenSSL 0x0090703f
debug1: Reading configuration data /home/per/.ssh/config
debug1: Applying options for *
/home/per/.ssh/config: line 2: Bad configuration option: ForwardX11Trusted
/home/per/.ssh/config: terminating, 1 bad configuration options

Unfortunately, all the world's installations of OpenSSH do not get
upgraded the instant a new version is released. So for years to come, we
will not have a simple answer to the user who wants to enable fully-
functional X11 forwarding. And needless to say, for users in the
situation that hosts with pre- and post-3.8 versions of OpenSSH
NFS-mount the same home directory, ssh_config is not an answer at all.

I fully understand the security implications and the reasoning behind
this change, but I still think it was a very bad decision compatibility-
wise. And I can't help having the feeling that if it wouldn't have been
made if it weren't for developers thinking of OpenSSH as "an OpenBSD
thing" rather than the ubiquitous piece of SW it has become.

--Per Hedeland
per@hedeland.org

Relevant Pages

  • Re: openssh-3.8p1 compile problem
    ... >>Sadly, I am not a good C programmer (actually, I am not a C programmer ... this same problem was present also in OpenSSH 3.7.x. ... each file by hand using VIM, so I have no *.rej files for sure. ...
    (comp.security.ssh)
  • Re: OpenSSH 3.8 Released
    ... Darren Tucker wrote: ... > It hadn't been put up when I posted originally,, but the canonical URL ... > for OpenSSH release notes is now: ... such as integrating in support for password expiration on various OS's. ...
    (comp.security.ssh)
  • Re: "host.deny" : very certain question for this function
    ... Darren Tucker wrote: ... > When it was built and installed, ... sshd or "man to openssh could'nt tell me that. ...
    (comp.security.ssh)
  • Re: Proposed enhancement to scp
    ... Darren Tucker wrote: ... >>How does one go about proposing an enhancement to a component of ... >>OpenSSH? ... I would like to see an option added to scp that would cause ...
    (comp.security.ssh)