From: Stefan Sperling <stsp@stsp.name>
Subject: Re: add ssh -J support to commands which use network
To: gameoftrees@openbsd.org
Date: Tue, 17 Dec 2024 06:19:49 +0100

On Wed, Dec 11, 2024 at 10:37:54PM +0000, Lucas Gabriel Vuotto wrote:
> On Wed, Dec 11, 2024 at 09:33:54PM +0100, Stefan Sperling wrote:
> > On Wed, Dec 11, 2024 at 09:31:32PM +0100, Stefan Sperling wrote:
> > > On Wed, Dec 11, 2024 at 06:27:53PM +0000, Lucas Gabriel Vuotto wrote:
> > > > On Wed, Dec 11, 2024 at 06:13:59PM +0100, Stefan Sperling wrote:
> > > > > Add a -J option to got clone, fetch, send, as well as cvg clone,
> > > > > update, commit. This allows ad-hoc use of SSH jumphosts without
> > > > > having to create entries in ~/.ssh/config.
> > > > > 
> > > > > For example, I found this useful when I wanted to fetch from a
> > > > > IPv6-only system while borrowing an IPv4-only wifi connection.
> > > > > 
> > > > > ok?
> > > > 
> > > > I don't know about the potential complexity, but wouldn't it be better
> > > > to have an ssh_opts in got.conf instead? Having a dedicated flag for
> > > > ProxyJump feels off for me.
> > > 
> > > But that would involve editing a configuration file, too. The point
> > > is avoid that overhead when reaching the configured remote without
> > > a jumphost or vpn or whatever is impossible.
> > 
> > And adding ssh_opts to got.conf would be no different to the current
> > way of setting per-remote ssh options, which is to add a Host entry
> > to ~/.ssh/config with whatever options are requried and using that
> > Host entry as the server URL.
> 
> I'd argue it's slightly different, because the remote block already
> exists in got.conf, and the scope is exclusively for got operations.
> 
> Alternatively, I believe that the Git way is GIT_SSH_COMMAND, which
> also seems more reasonable to me than adding -J to a bunch of
> subcommands.

It's only 3 subcommands, specifically those which use openssh to
talk to the network.

Git also supports other ssh implementations such as putty which use a
different set of command line options. Which is something we don't have
to worry about because we can expect openssh to be present on unix-style
systems. We don't need an abstraction that hides openssh from our UI.
Rather, tighter integration with openssh seems natural to me since our
network layer is openssh (ignoring our minimal HTTP support, which only
exists because most forges don't offer anonssh for public access).

> Alternatively, maybe a -o blah, with blah passed verbatim to ssh -o.
> 
> Anyways, this is a non-blocking opinion. I consider a dedicated
> ProxyJump limiting (what if I need ProxyCommand instead?) and the
> possiblity for something more generic, without dealing with ssh_config,
> is there, quite at hand. (I concede that got send -oproxyjump=6to4 $r
> doesn't looks as slick as got send -J 6to4 $r).

The -o option might be useful at times, but most of these options control
settings of a more permanent nature, such as use of allowed obsolete ciphers.
ProxyJump/-J can be used as an ad-hoc workaround for momentary issues with
the local network, much like -4 or -6.

By your reasoning, should ssh itself have a -J option?
While ssh(1) offers -J as a shortcut for ProxyJump, it does not offer such
a shortcut for ProxyCommand.

We can make other useful ssh options reachable via got's interface,
provided the option letters don't overlap.
Other useful options might be: -4, -6, -f, -F, -I, -i, -K, -S
Except for -f used by 'git send', all of these options could still be
allocated to got clone/fetch/send. I guess we can live without ssh -f?