@bagder I think curl should not support this.

I am open to an argument that the curl library offers so much high value scaffolding around the raw SSH protocol that adding remote execution seems like a small complexity addition with a potentially large benefit.

But curl is mainly written as a tool for uploading and downloading data transactionally. A remote execution mechanism might fit the implementation & design now, opportunistically, but could easily become a poorer fit during redesigns.

@bagder no.

@bagder
scope creep IMO

Next thing you know, someone will want to pass LANG or TERM env var to the executed command, or allocate a tty.

@bagder I mean, It's inevitable. Isn't it? 😉

@bagder No.

Even less so when it's slop.

@bagder Unless it requires command line arguments to indicate this is not a pure document request, no. Just like a GET should not act as a POST, buy 1000000x worse.

Also where would it be getting the credentials? Would curl/libcurl snoop your .ssh??

@bagder Nah, just sounds like another cluster of problems.

@bagder

Initial instinct says no, it feels like feature creep. Not SSH itself (as it does SFTP already), but the command execution part.

I feel like there is little to gain here, other tools already do this and it just increases maintenance scope and security risks

@bagder Nope. There's already a command for that.

@bagder

Interesting, yes. But i do not. Next to the very good reasons already mentioned here, i am also missing a convincing motivation behind this.

@bagder nope!

@bagder just the other day I was joking whether curl can be used as a transport for ssh ProxyCommand…

https://chaos.social/@zhenech/117151517621497909

@bagder FDISK:// when?

@bagder Ww have SCP and SFTP. ... why we need more?