Re: What's the deal on the -X vs -Y thing?
From: Dan Stromberg (strombrg_at_dcs.nac.uci.edu)
Date: 01/26/05
- Next message: Michael J. Pelletier: "Re: Restricing SSH Logins"
- Previous message: Richard E. Silverman: "Re: Restricing SSH Logins"
- In reply to: Darren Tucker: "Re: What's the deal on the -X vs -Y thing?"
- Next in thread: Darren Tucker: "Re: What's the deal on the -X vs -Y thing?"
- Reply: Darren Tucker: "Re: What's the deal on the -X vs -Y thing?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Wed, 26 Jan 2005 11:53:12 -0800
On Wed, 26 Jan 2005 02:26:25 +0000, Darren Tucker wrote:
>
> 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.
>
I stand corrected.
>
>>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?
I'd say that many admins at UCI don't so much "deploy" things, as just
reinstall a new base OS, or yum -y update, or something along those lines.
Many of them are grad students maintaining a faculty-owned *ix box, and
these grad students don't necessarily want to sink a lot of time (which is
time they'd rather be spending on their various classes and and
research projects and papers) into becoming a professional administrator.
And basically, yes, I do blame this on application developers, because
they need to realize that the time to maintain systems should be
-decreasing-. The microsoft world mostly gets this, as does the mac
world. So should the *ix world - otherwise, it's screaming "keep me in
niche markets!", and adding support to the belief of non-*ix people that
*ix is "too hard to maintain".
The perspective that it's OK to break backward compat because the admins
can be expected to sort out the problems, is increasingly outdated.
> 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.
Yes, I'm aware, but then there's the NFS (and other remote filesystems)
problem, as well as the fact that you can't just stuff the same thing into
all of your ~/.ssh/config's.
> 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.
Yes, I'll try to respect your decision. Meanwhile, I may start looking
into other projects like lsh and such, but as long as most of the
industry looks to OpenSSH for their ssh solution, I'm still at the mercy
of the OpenSSH developer's decisions anyway.
>
>>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?
Yes, mostly, though some nagios plugins enter the forumla as well.
> 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
Yes, I'd very much like to do something like this, but unfortunately,
deep-ssh cannot handle this kind of syntax in its current form.
> 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.
Yup. Least secure, but AFAIK, also the least time sunk into configuration.
> I posted info about an alternative configuration in response to you a
> while back (ProxyCommand and netcat/connect).
Yes, I recall that, and added a link to it (or was it something else
that's pretty similar?) on my deep-ssh page.
> 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.
I may have to revisit this, but then I'm probably still going to have to
rewrite deep-ssh to contend with the additional configuration on each
intermediate host.
I've been exploring pexpect and pyssh... And I'm hoping one or the other
will give me more complete bourne shell functionality (reinvent the wheel,
at least make it roll better). pexpect looks ideally suited, but then
doing everything on a pty screws up persuading ssh to pop up an X-based
password window instead of asking on the pty...
- Next message: Michael J. Pelletier: "Re: Restricing SSH Logins"
- Previous message: Richard E. Silverman: "Re: Restricing SSH Logins"
- In reply to: Darren Tucker: "Re: What's the deal on the -X vs -Y thing?"
- Next in thread: Darren Tucker: "Re: What's the deal on the -X vs -Y thing?"
- Reply: Darren Tucker: "Re: What's the deal on the -X vs -Y thing?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
