So tell me. Do you think #curl should support plain SSH:// URLs to execute commands remotely?
18
Replies
2
Boosts
@bagder Is there even a standard for SSH:// urls? First time seeing it in the wild.
@bagder if only there would be a command line program and a C library, to communicate with ssh servers, then curl wont have to....
@bagder I’d only allow that in the cli. If a user can execute the command “curl” it could be ok, though if it is executed in a different context (e.g. when calling curl library functions as a dependency), it could create unexpected security risks.
This comment is unavailable — it may have been deleted or is not visible to you.
But libcurl can’t support this except in builds where it links to libssh2. And this means that any program that might take advantage of this is also linked to libssh2. Which means that the real question is:
Is it easier for a program to encode something as a URL and a set of HTTP headers and pass it through libcurl’s APIs, or is it easier for it to pass those same values directly as arguments to libssh2 APIs?
I’ve never used libssh2, so I can’t say with 100% certainty, but I would be shocked if going via an API designed for a completely different kind of interaction is simpler.
The related question is whether there are use cases where you would want a program to either copy a file to / from a server or execute arbitrary code on that server via SSH, depending on user input. I can think of numerous reasons you would want to do that, but they’re all malware.
@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
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??
@dalias curl already does SCP and SFTP with credentials, so that's not really a new problem. But yeah, I don't feel that SSH has a good story for curl.
@bagder Nah, just sounds like another cluster of problems.
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 initial thought: "nooooooooooooooooooo....!!!!"
Second thought: probably not :p
@bagder Nope. There's already a command for that.
Interesting, yes. But i do not. Next to the very good reasons already mentioned here, i am also missing a convincing motivation behind this.
