Feature request/EOI: Match interactive config?

[openssh at tr.id.au]

I wasn't asking for help with workarounds. I am already aware of workarounds. I was asking for whether the idea of adding it to Match or similar would be supported.

You do it your way if you want. I don't see why you would care whether I want to do it some other way.

On Saturday, 4 May 2024 at 13:02, Michael Loftis <mloftis at wgops.com> wrote:

> Or just create bash (or whatever your favorite shell equivalent is) alias…
>
> alias issh=‘sah -F ~/.ssh/altcinfig’
>
> Or wrapper scripts in ~/bin/ you can invoke…
>
> Literally what I do for mosh, mosh+screen etc.
>
> --
> "Genius might be described as a supreme capacity for getting its possessors
> into trouble of all kinds."
> -- Samuel Butler
>
> On Fri, May 3, 2024 at 20:27 <openssh at tr.id.au> wrote:
>
>> Hey there,
>>
>> I often want different behavior in my ssh client depending on whether I'm logging into an interactive session or running a remote non-interactive command. We can see at, say, https://unix.stackexchange.com/a/499562/305714 that this isn't a unique wish, and existing solutions are kind of baroque. Typical reasons to do this are to immediately go into a screen or tmux session; for myself, I often want to relaunch bash as "bash -lo vi" on boxes where I don't have bashrc control. Basically, we want RemoteCommand to be turned on for interactive sessions, but ignore it when we've already specified a command as part of the client invocation.
>>
>> I wondered if there would be support for, or interest in, adding a new condition called "interactive" (or similar) to the Match keyword? Although my use case is for client-side, I guess it may also make sense in sshd_config. I can imagine cases where sysadmins would want to present different behavior depending on whether a client is coming in interactively or running a command.
>>
>> Alternatively, could there be a new option which specifies how to resolve conflicts between command-line commands and RemoteCommand directives? Eg something like "RemoteCommandOptional yes" which can be paired with RemoteCommand. This would allow a default RemoteCommand which can be overridden by commands passed on cli.
>>
>> Or have I overlooked an already-existing simpler/better way of toggling different configurations for interactive vs non-interactive sessions exist, when serverside control is not an option? Sorry if this was already discussed before, nothing from this mailing list turned up in a web search about the topic.
>>
>> Cheers,
>>
>> Tim
>>
>> _______________________________________________
>> openssh-unix-dev mailing list
>> openssh-unix-dev at mindrot.org
>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev