Hey. For some configuration options which specify a file, we also have a corresponding one specifying a command, namely: GlobalKnownHostsFile UserKnownHostsFile and KnownHostsCommand I would find it useful, if something similar could be offered for RemoteCommand (well that's the one I'd have a use case for - for LocalCommand it doesn't really make sense anyway). I have some special configurations that set a quite large RemoteCommand (which starts a remote systemd unit for a VNC server, sets traps on INT/EXIT/QUIT to stop the server, but a special one for HUP, so that it can be left running, and later reconnected to, if just the connection dies... well and it does some more stuff). AFAICS there is no site limit for the RemoteCommand, but it's still quite messy to edit within ssh_config. So one solution would be to have a RemoteCommandCommand, which itself is executed locally and gives back some string that ssh would use as RemoteCommand (executed remotely). Simply reading a script could be done via a RemoteCommandCommand like "cat myscript.sh". I'm not sure whether the remote command could contain in principle newlines (and just the limitations of RemoteCommand prevent these. If it can (which I guess9, any script would already work, if not, then one could perhaps give an example command that "serialises" a script, though I think that's actually not easy,... at least it's not enough to replace any newline with ';'. Thanks, Chris.
You can already do this with a trivial shell pipeline: yourcommand | ssh yourserver /bin/sh or the equivalent shell wrapper around ssh. I don't see a general need for what you're describing.
Well that doesn't work as soon as you want pipe something to the shell "script's" stdin... or if you want to have an interactive session. A wrapper command is in principle of course possible, but still less easy to use (one needs to distribute it everywhere, write it smart enough so that it only kicks in for the desired connections, etc.) Anyway... I just reported it because I assumed it would be rather easy to do... I don't strictly depend on it so just close if you don't like the idea :-D Cheers, Chris.
(In reply to Christoph Anton Mitterer from comment #2) > Well that doesn't work as soon as you want pipe something to the > shell "script's" stdin... or if you want to have an interactive > session. That's true, however for those cases you could do ssh yourserver "$(yourcommandcommand)" instead. It still doesn't seem like this is something that would be generally useful so I'm going to close this bug. Thanks anyway.
OpenSSH 9.3 has been released. Close resolved bugs