The ssh client currently has a few subprocesses that it might invoke.  For example, ProxyCommand and LocalCommand.

Those processes are invoked without any knowledge of the configuration of the ssh session being invoked, but some commands might alter their behavior based on the ssh configuration.

My proposal is for ssh to export its current configuration to the environment established for the invoked subcommand.  So the child process could (for example) examine ${OpenSSH_hashknownhosts} to decide how to update a known_hosts file.

This is similarly useful to sshd's -C and -T options (though the mechanism is different, of course) -- so aligned tools don't need to re-implement (or track) OpenSSH's config file parsing code.

One way to approach this would be to allow something similar to -C -T, but for the client configs instead of the server configs.  However, this solution wouldn't address a situation where a user had invoked ssh like:

  ssh -oHashKnownHosts=no -oLocalCommand=whatever user@host

(that is, the "whatever" command couldn't determine that HashKnownHosts was "no" for this session just by parsing the client configs).

Is this something that seems like it would be useful to other people?  I'm willing to work on a patch.