jcs:open needs options for strict host keys

[philshafer]

Need an option for jcs:open to pass options to the underlaying ssh invocation, including:

• argv[argc++] = ALLOCADUP("-oStrictHostChecking=no");

This can be specific, like:

var $option = {
"no";
}

or generic, like:

var $options = {
    <ssh-option> "-oStrictHostChecking=no";
}

[aburston]

In order to address Juniper PR 891767 this would need to be a command line option to juise.

This is so that when juise is executed from the command line via space it could switch off host checking by specifying an option, for example:

juise --nostricthostchecking ...

[philshafer]

On Oct 28, 2013, at 7:26 AM, Ashley Burston wrote:

This is so that when juise is executed from the command line via space it could switch off host checking by specifying an option

Won't this open jspace to man-in-the-middle attacks?

Thanks,
Phil

[aburston]

Well space is already vulnerable to man in the middle attacks because there is no mechanism for asking the user whether to accept a host key or not. Space potentially already has that problem for integrating with devices. The only reason this has come up is because juise reuses ssh via exec instead of going direct via a library.

Where this comes up is when a user clears and reinstalls an rma'ed device and wants to bring it back up on the same IP with a different fingerprint. Space has no way of deleting the known hosts file. This would be the most elegant way of solving that problem.

This is a space design decision, not one that I have the authority to address. However I am tasked with making sure that when you bring the new device up space will actually speak to it instead then forever refusing to speak to the device.

[aburston]

As an additional aside Space should always be installed in a properly fire-walled network and has access to the core routers of an enterprise. If a router is replaced via a man-in-the-middle attack, then space is the least worrying element in this scenario.

For customer premises equipment there would be a case for this. The problem is that most of the interaction does not go via the on board SSH binary as is the case with juise, so I am uncertain as to how this problem is handled for those scenarios that fall outside of the influence of juise.

[philshafer]

On Oct 28, 2013, at 11:09 AM, Ashley Burston wrote:

For customer premises equipment there would be a case for this. The problem is that most of the interaction does not go via the on board SSH binary as is the case with juise, so I am uncertain as to how this problem is handled for those scenarios that fall outside of the influence of juise.

Okay, I'll add the option. At some point, as we move SSH connections to the "mixer" utility, we should talk about how to route security requests back to jspace.

Thanks,
Phil

[aburston]

I agree, what I would really like to do is create a JNI version of juise that can used directly from java without having to use perl and expect scripts and all kinds of horrific wiring. That is the promised land I am shooting for. I would like the same thing with libslax so we can do syntax validation in the editor.

[aburston]

B.T.W I would be happy to write the wring myself if it will save you time...

[aburston]

juise -t trace.log -v --ssh-options "-oStrictHostKeyChecking=no" ~/shell.slax

This seems to do the trick actually.