https://bugzilla.mindrot.org/show_bug.cgi?id=1766

           Summary: ssh should provide the current session configuration
                    to subprocesses it invokes (via the environment?)
           Product: Portable OpenSSH
           Version: 5.5p1
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: ssh
        AssignedTo: unassigned-b...@mindrot.org
        ReportedBy: d...@fifthhorseman.net


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 u...@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.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

Reply via email to