Preserving argument splitting with SSH

[Lee Eakin]

I see what you are getting at now.  Perl has some magic to decide whether
or not it should invoke /bin/sh or just exec a command directly.  I don't
like the idea of magic (especially in a context of security), but an option
to make ssh exec a command directly instead of thru the shell could be
quite useful.  Perhaps a '-o UseShell=no' or something similar in nature.
It would still need to honor the 'command=' in the authorized_keys file so
no holes are opened, but I can see how this sort of option would simplify
automation.
  -Lee

---begin quoted text---
> To: Lee Eakin <leakin at japh.itg.ti.com>
> Cc: openssh-unix-dev at mindrot.org
> Subject: Re: Preserving argument splitting with SSH
> From: Greg Badros <gjb at cs.washington.edu>
> Date: 15 Dec 2000 08:54:12 -0800
> X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald"
> 
> Lee Eakin <leakin at japh.itg.ti.com> writes:
> 
> > The arg splitting is not preserved because it is parsed once by the local
> > shell, and then again by the shell on the remote system.  When the remote
> > system's shell sees it the quotes are already gone.
> > 
> > Try this:
> >     ssh gellar args foo bar \'baz bong\'
> > or:
> >     ssh gellar args foo bar "'baz bong'"
> >  
> >  I think you'll see it parses properly then.
> 
> Right; I don't think I'd written clearly enough: you do not always need
> to run a shell at the remote end.  In my example, just exec'ing with the
> appropriate argv and environment is sufficient.  I was wondering about
> making ssh just Do The Right Thing (e.g., if there are no shell globs or
> shell metacharacters it clearly can just exec).  Alternatively, perhaps
> there could be an option to just make the remote side do an exec
> directly rather than use a shell.
> 
> Thanks for the response, Lee.  And I apologize for not mentioning the
> two possible solutions I had in mind.
> 
> Thanks,
> Greg
> 
> 
> >    -Lee
> > 
> > ---begin quoted text---
> > > Delivered-To: openssh-unix-dev-list-93873 at mindrot.org
> > > To: openssh-unix-dev at mindrot.org
> > > Subject: Preserving argument splitting with SSH
> > > From: Greg Badros <gjb at cs.washington.edu>
> > > Date: 14 Dec 2000 19:11:56 -0800
> > > X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald"
> > > 
> > > I'm using:
> > > 
> > > % ssh -V
> > > SSH Version OpenSSH-1.2.3, protocol version 1.5.
> > > Compiled with SSL.
> > > % uname -a
> > > Linux gellar 2.2.13 #1 SMP Wed Dec 29 14:07:41 PST 1999 i686 unknown
> > > 
> > > and am wondering whether it's a fundamental shortcoming of the SSH
> > > protocol that argument splitting is not preserved from client to server, 
> > > but instead the argument list is re-split on whitespace.  E.g., from my
> > > machine `gellar', I execute:
> > > 
> > > % ssh gellar args foo bar 'baz bong'
> > > ARG0 = /usr/home/gregb/bin/share/args, NumArgs = 4
> > > 1 = "foo"
> > > 2 = "bar"
> > > 3 = "baz"
> > > 4 = "bong"
> > > 
> > > (where args is just a script that outputs the arguments), instead of
> > > what I get when I run args directly:
> > > 
> > > % args foo bar 'baz bong'       
> > > ARG0 = /usr/home/gregb/bin/share/args, NumArgs = 3
> > > 1 = "foo"
> > > 2 = "bar"
> > > 3 = "baz bong"
> > > 
> > > which is much better.  If it's not a limitation of the protocol, then it 
> > > should be a pretty easy (and valuable!) fix.
> > > 
> > > Please include me in replies as I'm not on the list.
> > > 
> > > Thanks,
> > > Greg
> > ---end quoted text---
> > 
> > -- 
> >     Lee Eakin - leakin at ti.com - Naming Services, Texas Instruments   -o)
> >                 [ permanent e-mail: Lee at Eakin.Org ]                  /\\
> >                                                                     _\_v
> > Allen's Axiom:
> >   When all else fails, follow instructions.
---end quoted text---

-- 
    Lee Eakin - leakin at ti.com - Naming Services, Texas Instruments   -o)
                [ permanent e-mail: Lee at Eakin.Org ]                  /\\
                                                                    _\_v
If nobody uses something, there's probably a reason.