"GOT", but the "O" is a cute, smiling pufferfish. Index | Thread | Search

From:
Kyle Ackerman <kack@kyleackerman.net>
Subject:
Re: add ssh -J support to commands which use network
To:
Lucas Gabriel Vuotto <lucas@sexy.is>
Cc:
gameoftrees@openbsd.org
Date:
Thu, 12 Dec 2024 01:13:35 +0000

Download raw body.

Thread
On Wednesday, December 11th, 2024 at 4:37 PM, Lucas Gabriel Vuotto <lucas@sexy.is> 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.
> 
> 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
Not sure if Got needs to be that transparent or feature-parity to ssh.
I think a good separation is command-line args helps figure out how 
to get to a host, the got.conf helps figure out what to do once it gets 
there. I would argue that Got should not allow a user to tweak 
ProxyCommand. A useful antidote for me is using a ssh bastion to get 
into my home network. Adding a command-line arg is a lot easier than 
consistently modifying got.conf 

> 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).