From: Omar Polo Subject: Re: add ssh -J support to commands which use network To: Stefan Sperling Cc: gameoftrees@openbsd.org Date: Tue, 17 Dec 2024 20:48:35 +0100 On 2024/12/17 06:19:49 +0100, Stefan Sperling wrote: > 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. Makes sense to me to add -J (or equivalent.) This maybe doesn't rule out having an option on got.conf, option on which I don't have a strong opinion, but having the freedom to quickly pass through a jumphost seems nice enough to warrants a new flag. > 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). also makes sense to me; we should try to keep things simple rather than aim for infinite support. > > 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. fwiw I agree. passing arbitrary arguments to ssh(1) is outside of the scope for a wrapping utility like `got send'. Not sure it warrants the extra complexity either. > 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? not sure how many of these are actually useful (thinking in particular of [fIiKS].) folks can use custom configuration in their ~/.ssh/config for them. I might be convinced about -F, in some situations I've used an alternate configuration file and that could indeed be handy as well. my two cents :)