Per Client Config File

[tjkolev]

I have a number of OpenWRT routers, and all are running Dropbear SSH. For various reasons I ssh to other machines from the routers. A file like that OpenSSH one (~/.ssh/config) would be handy. It's not the first time I was looking for that feature, but now I came across this comment by Matt Johnston:

... but I'd be happy to take a patch if someone wants to make it work.

(https://www.mail-archive.com/[email protected]/msg01914.html)

Well, here's an offer for review.

The support is minimalistic. Just the very basics - an alias that defines the real remote host, port number, user name, and identity file to use. This covers all of my use cases, and probably most for others. Then again, as Matt says in the comment above, the same can be accomplished with appropriately named scripts. Still, it opens the possibility to add more advanced capabilities.

The support for the config file is not compiling by default. It is behind the DROPBEAR_DEFAULT_USE_SSH_CONFIG define, which can be enabled in the localoptions.h if this feature gets vetted.

The config file is hard coded to ~/.ssh/dropbear_config. I tested using the OpenSSH ~/.ssh/config as the keywords are the same. There were no issues for either client. But that may not be the case in the future. And it's easy to see problems with having what are distinctly separate semantics being merged into a single file.

All the tests I ran were manual. I see there is some test harness in test, but I was not able to run it successfully. And could not find documentation about it in the source.

Updated the dbclient.1 manpage, Files section. Normally a configuration file would have its own manpage, but I decided this one was too simple for that.

tjk :)

[tjkolev]

Before merging I'd like to add a fuzzer target for the config parser (I can do that).

I don't have any experience with fuzzing. I would like to try and come up with something. Will let you know when I give up...

tjk :)

[tjkolev]

@mkj, I updated the changed files with your suggestions. And I found some time to see what I can do with fuzzy testing the added code for config file. Didn't get far. I ran the following:

./configure --enable-fuzz
make fuzzstandalone
./fuzzers_test.sh

The last one fails - exit code 1. I pulled the fuzzcorpus repo, but could not figure the wiring. If I am to add fuzzy config test I will need some pointers on how to generate the fuzzy input, and then how to use that data. Any help would be appreciated.

Cheers! tjk :)

[mkj]

The fuzzstandalone code performs a kind of regression testing, using a fixed corpus of fuzz results that previously was created by running oss-fuzz. The fuzzstandalone harness just feeds in pre-existing files to the fuzz targets. I see what you mean about it failing - that seems like a pre-existing bug being triggered the corpus, I'll investigate.

The real fuzzing happens by running oss-fuzz in a docker container - it links to libfuzzer that generates new random inputs. Following these instructions, using fuzzer-pubkey as an example target:

git clone --depth=1 https://github.com/google/oss-fuzz.git
cd oss-fuzz
python3 infra/helper.py pull_images
python3 infra/helper.py build_image dropbear
python3 infra/helper.py build_fuzzers --sanitizer address --architecture x86_64 dropbear /path/to/your/dropbear_dir
mkdir newcorpus
python3 infra/helper.py run_fuzzer --corpus-dir=newcorpus dropbear fuzzer-pubkey

Then you let it run for a while and it should eventually generate some interesting authorized_keys file lines. The docs also have instructions on how to generate html code coverage reports to see if the fuzzer is getting places.

So a new target would be similar to fuzzer-pubkey.c, but instead of calling fuzz_checkpubkey_line() (from svr-authpubkey.c) it would call something in the client config parser. That's a bit trickier since the client config parser just has the one function taking a file - you could split it into a function that takes a line, which is similar to what I did when adding the checkpubkey fuzz target. I guess calling multiple lines in a single fuzz pass might also help, but that's later along.

[mkj]

I see what you mean about it failing - that seems like a pre-existing bug being triggered the corpus, I'll investigate.

There's a mismatch between the fuzzing malloc wrapper m_free() vs the non-wrapped malloc() / XMALLOC() if it builds with bundled libtomcrypt. So when fuzzing, make sure to configure --enabled-bundled-libtom. I'll try fix the mismatch eventually.

[crass]

What's the status of this PR? This would be useful to get merged. This way someone can go about actually supporting the -F option.

[tjkolev]

What's the status of this PR? This would be useful to get merged. This way someone can go about actually supporting the -F option.

Sorry, I dropped the ball on that one. I should've added some fuzz testing, and I never got around to it. Will need to renew my efforts.

tjk :)

[mkj]

Thanks tjk, I've rebased this manually and merged it (with a few changes on top, and fuzzing)