dkg at fifthhorseman
Jul 13, 2009, 4:18 PM
Post #7 of 11
(1626 views)
Permalink
|
|
Re: Feature request: "SetupCommand" invoked before connecting
[In reply to]
|
|
On 07/13/2009 06:47 PM, Peter Stuge wrote:
> Helmut Grohne wrote:
>> Adding a wrapper still imposes the disadvantages mentioned before
>> (second option parser, scattered configuration). Yes, it will work
>> (around).
>
> Sorry, I don't understand which disadvantages you refer to. The
> suggestion is to rename the original ssh binary from ssh to for
> example ssh.orig and then to create a script named ssh which does
> everything you need, before finally execing ssh.orig.
I think the disadvantage Helmut was referring to is when you want a
script that does something smart based on the options with which OpenSSH
is invoked.
For example, when ssh'ing to machines A, and B, first execute a known
port-knock sequence on the relevant host. Before connecting to machines
in domain X, add a given key to the ssh agent. Before connecting to
machine C, which is known to have a volatile yet published host key,
refresh its host key from a trusted source. When connecting as user U
to machine D, verify that a given smartcard is present before connecting
to avoid triggering an overeager packetfilter. When connecting to
non-standard ports on machine E, pre-fetch authentication credentials
from a particular kerberos domain.
In each of these examples, the invoking script needs to know at least
the name of the target host for the invoked connection. In the more
sophisticated examples, it might want to know the port number, username.
I can imagine more complex examples where it would be useful to know
things like whether a pseudoterminal was requested, or local or remote
port forwarding.
I think the point of the original poster is that any wrapper script
would need to be able to effectively parse all the relevant options (and
at least know enough to ignore the irrelevant ones). This means
implementing an SSH command-line and configfile option parser in the
wrapper script before re-execing ssh itself.
This seems wasteful and difficult to maintain, as a perfectly good ssh
command-line and configfile option parser already exists, in the form of
the OpenSSH codebase.
The proposed SetupCommand (if it were allowed to contain the same
%-escaped substitudions as, say, ControlPath) would be useful in all the
examples above, as the command could be given the exact options
explicitly, without needing to worry about option parsing.
I think such a command would be a useful feature.
--dkg
|
setupcommand.diff
