Actually it's worse than that.

In another profile where I specify [-o "ForwardAgent no"] in my SSH arguments I get the following when I attempt to connect:

Loading NaCl plugin... done.
ssh: connect to host no" port 22: Connection refused
NaCl plugin exited with status code 255.

fairly certain it's "always" been like this.  you need to use -- to separate the args from the remote command.

that said, looking at the parsing code, i don't think it'll be a big deal to improve this.

I'm almost positive that the profile with [-o "ForwardAgent no"] was working at some point in the last few weeks since I was playing with ssh-agent auth to non-Google hosts. (and it's purely an option setting, not a remote command)

I'll see if I've done something terribly wrong

we can reliably construct the command line in the non-sftp case because ssh specifically supports that scenario -- it scans all the options until it hits the first non-option, extracts that as the hostname, and then rescans the remaining.  so if we just blindly append the argstr field, it'll work.

but that'll re-break sftp mounting:
  https://chromium-review.googlesource.com/490906

parsing the argstr to detect the command line isn't trivial because of the forms:
  -oForwardAgent=no
  -o ForwardAgent=no

we'd have to replicate the getopt parsing so we know which flags take options and which ones don't :/.

we don't want to throw away the argstr completely in the sftp case because there are flags in there we care about (like -4 or -6).  and it'd be confusing to silently ignore.

similarly, we could make it so things just work more often by requiring -- in the sftp case, but not otherwise.  it would be confusing.  but maybe not.  the current behavior is confusing too.

i don't think quoting works like you've shown.  normally the shell takes care of dequoting and turning into a single arg.  but we don't do that in Secure Shell anywhere, so the program sees the actual quotes.  as if you used `ssh -o \"ForwardAgent no\" ...`.  so you want to drop the quotes and replace the space with an equal sign.

this is all a bit fragile when you step outside the bounds.

we could patch openssh so we'd pass the sftp flag in a secondary set of flags so we leave the main argv alone.  then we could merge the argstr in and let ssh do all the parsing.

i'm going to look at changing the js<->ppapi<->ssh_main interfaces so that the subsystem field is passed down independently of argstr.  this way the command line ignore logic is done in ssh_main and is fairly bullet proof.

then i'll change the command line appending so we do it blindly w/out parsing and leave it to ssh_main to handle things.  this will make secure shell behave much more like `ssh ...` and not require you to put "--" in explicitly.

that leaves your usage of quotes.  i don't think we want to support those for this case alone since there are alternatives -- use an "=" instead of a space to join the two parts.  if you can think of a command line option where using quotes to join them makes sense, we can re-evaluate.  in the mean time, i'll add some tooltip text for this field that documents the expected format.

was there anything else here ?

ssh_config(5) says:

> Configuration options may be separated by whitespace or optional whitespace and exactly one ‘=’; the latter format is useful to avoid the need to quote whitespace when specifying configuration options using the ssh, scp, and sftp -o option.  Arguments may optionally be enclosed in double quotes (") in order to represent arguments containing spaces.

So my usage of quotes will apparently still be broken, but I believe that the change is worthwhile.

It also looks like we _may_ be able to use [-o Foo="bar baz"] which is odd since I can't find a single option in ssh_config(5) that calls for a value containing whitespace.

Passing the baton.

ssh_config(5) documents the format of the ~/.ssh/config file, not the format of passing options on the command line :)

that said, there are some options which take a space delimited list like CanonicalDomains.  since quote processing is a bigger can of worms than what i'm proposing here, i've forked that to  issue 725625 .

The following revision refers to this bug:
  https://chromium.googlesource.com/apps/libapps/+/be952e573afb2d3894a1752d3df148d8a3399291

commit be952e573afb2d3894a1752d3df148d8a3399291
Author: Mike Frysinger <vapier@chromium.org>
Date: Wed Jul 26 20:40:06 2017

nassh/ssh_client: rework how we pass sftp subsystem down

Rather than re-use the -s argument to select the sftp subsystem, add a
new parameter to the plugin API so we can signal this independently of
the command line.  By itself, this isn't terribly useful (and is a bit
redundant), but in a follow up CL, it allows us to simplify the command
line parsing on the JS side significantly.

BUG= chromium:725292 

Change-Id: I55d04617050a3f7c76e3ecf61138ef3fad2f711c
Reviewed-on: https://chromium-review.googlesource.com/586672
Reviewed-by: Brandon Gilmore <varz@google.com>
Tested-by: Mike Frysinger <vapier@chromium.org>

[modify] https://crrev.com/be952e573afb2d3894a1752d3df148d8a3399291/nassh/doc/hack.md
[modify] https://crrev.com/be952e573afb2d3894a1752d3df148d8a3399291/ssh_client/src/ssh_plugin.cc
[modify] https://crrev.com/be952e573afb2d3894a1752d3df148d8a3399291/ssh_client/openssh-7.5p1.patch
[modify] https://crrev.com/be952e573afb2d3894a1752d3df148d8a3399291/nassh/js/nassh_command_instance.js

The following revision refers to this bug:
  https://chromium.googlesource.com/apps/libapps/+/3d500c3542efcd0c07fa4f141eaa59e7623e1068

commit 3d500c3542efcd0c07fa4f141eaa59e7623e1068
Author: Mike Frysinger <vapier@chromium.org>
Date: Fri Aug 04 20:36:45 2017

nassh: rework user command line processing

Move the custom user command line options to the end so we always append
them.  This makes things "just work" more often when users specify remote
commands and behave much more like native `ssh`.  We also no longer need
to check the sftp mount state because the ssh plugin will throw away the
extra args for us.

We still don't handle quotes or embedded whitespace correctly, but we can
address that in a follow up if/when we supported quoting at all.

BUG= chromium:725292 

Change-Id: Ib0d438cbc7a77366881cc7a058fc3d060f0085a1
Reviewed-on: https://chromium-review.googlesource.com/600637
Reviewed-by: Brandon Gilmore <varz@google.com>
Tested-by: Mike Frysinger <vapier@chromium.org>

[modify] https://crrev.com/3d500c3542efcd0c07fa4f141eaa59e7623e1068/nassh/js/nassh_command_instance.js

this will be fixed in 0.8.36.10.  specifically, you no longer need to explicitly pass "--" for the remote command.  checked both sftp mounts and remote connections.