Created attachment 3438 [details] Pass address family switch to proxy command Generally, proxy command is used to connect to proxy servers and the address family of the target host is up to the decision of the proxy command itself (regardless it is netcat, another ssh or something else). Currently, hints from commandline (-4, -6) are not used at all and not passed to proxy command similarly as any other hints from configuration files (unless the proxy command is ssh too and the proxy host has specific AddressFamily directive). My suggestion would be to provide a new replacement percent-token to inform the proxy-command about the preferred address family (%f) to provide either -4, -6 or empty string if no preference was given. See the proposed patch
I'm not sure about these semantics because it's significantly different to that of the existing TOKENs. Where possible we try to keep them consistent across all keywords than can use them. I can imagine use cases where the other keywords might also want access to this information and as it stands this isn't really suitable for that. None of the other TOKENs are in the form of a command line flag, and they always expand into something. This one only expands into something some of the time. I grant it's convenient for this exact use case, but my concern is it will be difficult or impossible to use for any other case.
Thank you for feedback. That was the reason why I started this discussion on the mailing list whether the might be some other use cases that we should consider when implementing this feature. https://lists.mindrot.org/pipermail/openssh-unix-dev/2020-August/038698.html I see it is quite strictly tied to (proxy) commands, which is probably fine (as we already have for example %T only for local commands). The choice of whole command-line switch was for convenience as -4 and -6 are quite standard and there is usually no way how to express default family choice (any/unspec) while checking various netcat implementations. But if somebody can come with more suitable solution, I am fine with that. For the sssd use case mentioned on the mailing list, we are quite free to use anything, for example some environment variable to pass this information if it would be more suitable (but it would be useless for netcat or other tools at this moment).