When multihop executes dbclient it should only add -i arguments
from the original commandline, not the default id_dropbear key.
Otherwise multiple -i arguments keep getting added which
results in servers disconnecting with too many auth attempts
For the sake of review, this commit alters only the code; the affiliated
comments within the source files also need to be updated, but doing so
now would obscure the operational changes that have been made here.
* All on/off options have been switched to the numeric `#if' variant;
that is the only way to make this `default_options.h.in' thing work
in a reasonable manner.
* There is now some very minor compile-time checking of the user's
choice of options.
* NO_FAST_EXPTMOD doesn't seem to be used, so it has been removed.
* ENABLE_USER_ALGO_LIST was supposed to be renamed DROPBEAR_USER_ALGO_LIST,
and this commit completes that work.
* DROPBEAR_FUZZ seems to be a relatively new, as-yet undocumented option,
which was added by the following commit:
commit 6e0b539e9c
Author: Matt Johnston <matt@ucc.asn.au>
Date: Tue May 23 22:29:21 2017 +0800
split out checkpubkey_line() separately
It has now been added to `sysoptions.h' and defined as `0' by default.
* The configuration option `DROPBEAR_PASSWORD_ENV' is no longer listed in
`default_options.h.in'; it is no longer meant to be set by the user, and
is instead left to be defined in `sysoptions.h' (where it was already being
defined) as merely the name of the environment variable in question:
DROPBEAR_PASSWORD
To enable or disable use of that environment variable, the user must now
toggle `DROPBEAR_USE_DROPBEAR_PASSWORD'.
* The sFTP support is now toggled by setting `DROPBEAR_SFTPSERVER', and the
path of the sFTP server program is set independently through the usual
SFTPSERVER_PATH.
Small change that warns the user if the current user cannot be identified rather than aborting. This came in handy when I put dropbear on a dlink that did not have a true user environment. Falling back on the "-l" option and user@ options works just fine as a client. The only implication I found is that the -J option will fail ungracefully without a known own_user.
