dbclient: support -o StrictHostKeyChecking

[stokito]

Fixes #226

[stokito]

I added other options that already have a flag. This will make interoperability with OpenSSH better because -K -J flags have a different meaning. So with the options we can help to write scripts that will work similarly. Unfortunately this also makes code bigger but i hope that not so much. We can make a condition to compile only those options that doesn't have a flag or the flag meaning differs. Still I believe that if someone have a place for Dropbear then they are probably ready to have some extra kilobytes.

[stokito]

@Zepmann please test the StrictHostKeyChecking and BatchMode that you asked for in #224

[Zepmann]

Tested.

-oBatchMode=yes seems to work fine. 👍

The behavior of -oStrictHostKeyChecking=accept-new is not what is expected. With -oStrictHostKeyChecking=accept-new, the SSH client does not write the server's public key to known_hosts. If a known_hosts file does not exist, it will be created with 0 bytes of content. If known_hosts does exist, its content is not changed and the modification date is not updated, hinting that nothing is written/changed.

[stokito]

Right, so the dbclient should also store the hostkey to known_hosts without confirming. I may try to fix that but in nearest time may not have a time for this.

[stokito]

@Zepmann I fixed the bug in a separate https://github.com/mkj/dropbear/pull/271

I don't know if Matt will accept this PR but at least for that bug fix should be easier to pass review. If you can, please merge that branch and re-test. Thank you

[mkj]

Thanks, this has been requested a bit. I still need to review the code.

One thing I notice, BatchMode disables password auth unconditionally. But it seems it should be allowed if using DROPBEAR_PASSWORD env var, or SSH_ASKPASS? (I can make the changes on top of this PR).

[stokito]

will add a fix in a minute

[Zepmann]

BatchMode should prevent the need for any user interaction. All other program behavior should be as usual from an admin expectation perspective.

Just my 2 cents. Thanks for the work so far, @stokito and @mkj.

[stokito]

I moved the batch mode cheking before the getpass() call.

[stokito]

Updated man page with new options

[HansH111]

For multihop support you need to change multihop_passthrough_args() in cli-runopts.c and pass the -o values.

[stokito]

The options shouldn't be applied to jump servers. Or maybe the dropbear supports this? If you know how to make it please send a PR once this become merged.

[HansH111]

Maybe not, but I see -y -y being passed when using multihop in function multihop_passthrough_args() in cli-runopts.c

[HansH111]

I just checked and removed the -y -y in that function and when I do a multihop now, it asks for confirmation because the hostkey is not in the trusted host file.

[stokito]

I tested how the PasswordAuth and BatchMode works with keyboard interactive auth. No issues with this.

The BatchMode=yes won't stuck in interactive auth but it will try it and fail only when the interactive asks for a user input. This is even better behavior that OpenSSH client have. For example you can ssh to srv.us (free ssh tunnels provider) and it will ask for interactive mode but authorize immediately without asking.

When the PasswordAuth=no it will stuck in the interactive mode and wait for a user input.

I made a simple SSH server in Golang to test this. If you'll need it I'll share.

[HansH111]

Added a pull request for -o BatchMode=yes and also passed it when multihop was selected. I am not very experienced in git.... I have no idea how to put it in this pull request .

[stokito]

@HansH111 make an archive and send to me at [email protected]. You can't add commits to another one's PR

[mkj]

I've pushed a few changes on top of this, and added in PR #281 from @HansH111 .

stricthostkeychecking=yes is changed a bit, previously it was asking whether to add.

[stokito]

Thank you, I'll retest today.