Feature request/EOI: Match interactive config?

[Michael Loftis]

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
>