So tell me. Do you think #curl should support plain SSH:// URLs to execute commands remotely?
47
Replies
2
Boosts
@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.
@bagder just the other day I was joking whether curl can be used as a transport for ssh ProxyCommand…
@bagder Ww have SCP and SFTP. ... why we need more?
@bagder i get the feeling that this could be used for some nasty things. Or at least that or at least that this could make RCE easier in some setups where curl ist invoked with a user-supplied URL
@bagder how is it different from https://example.com/execute.api/shutdown%20-h%20now ? :)
but now: “ssh://host.example.com/command=shutdown -h now” instead of passing it with a custom -X
SSH is the transport in this case in stead of HTTPS. But otherwise, it is a ‘URL" that is requested.
For a command like “ps aux" it would make more sense in a way, as then you got a question and an answer (in plain/text or if there is a tool like ‘jq' with json mode).
You would have to come up with a proper SSH URL scheme though. But if one would do that it would fit curl better, yet another special option not so much.
@bagder I don't sense a particular demand for this feature from users.
@bagder My concern is that I don't think libssh2 uses `~/.ssh/config`. There are things that don't seem to fit in a URI. Jump hosts, identity files and agent forwarding would be the big ones from my usage. I usually use the config file to do that, but it also works on the ssh command line.
But if scp/sftp URIs already exist, maybe this would be fine?
@bagder it'd certainly be convenient sometimes... I'm far from qualified to talk about the implications of the increased attack surface area, but it kinda fits in the sense that for any long-lived tool or lib one expects gradual scope growth and hegemonisation. If the scope of curl is URI resolution, adding support for ssh scheme doesn't sound mad at all, and if it's not, where are the natural boundaries? I say do it, why not.
@bagder no. at the moment I expect curl to fetch and put things, not execute things.
also..
Assisted-by: an actual person <human@skunkwerks.at>
@bagder Seems out of scope to me, but it's your project and I'd have already made a different decision with regards to AI-generated submissions.
@bagder It would be fair only if local execution `curl --exec example.com/install` would be supported as well.
@bagder heck no. security smell & pinata for hackers. curl attracts enough scrutiny by bad actors as it is
@bagder speaking of which, I'd love to see grpc:// :)
@bagder no, because I am a strong proponent of the UNIX principle. Curl does one thing great, let ssh do that other job.
can I also remind you all that curl already speaks SCP and SFTP, in command line tool and library...
@bagder adding 'ssh://' seems like it would introduce a fair amount of confusion. What features of an ssh client should curl itself implement? Does that implementation become some sort of ad hoc RPC protocol?
@bagder for me, that sounds like introducing a new kind of command line injection🫣
@bagder my impression is that the main scope of cURL is to fetch remote files (and push files to remotes that supports it).
From that point of view:
- support the SCP and SFTP protocols makes totally sense
- support remote execution of arbitrary command would fall under scope creep (and open too mant new cans of worms) (and also increase attack surface by giving opportunity for new creative abuse of the feature)
@bagder Hm, ssh can already to it: https://malcontentcomics.com/systemsboy/2006/07/send-remote-commands-via-ssh.html why mis-use curl then for this?
@bagder IMHO no; we have ssh already for that.
@bagder throw in a TUI and vim bindings while you're at it /s
and kids, don't forget that curl is even more a library than a command line tool...
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 this could be practical in a similar way to KDE's fish protocol. One could use cat or dd in case the server side lacks support for SCP or SFTP.
But generally it's really up to what people enjoy doing with the tool. I can write scripts that use wget and ssh just the same, so in this case it would really be the library use case where curl would stand out. In some cases this might really help to interact with embedded devices as which run a version of Dropbear without SCP and SFTP support.
@bagder curl can do POST http requests so seems like a fine addition
@bagder No, don't do it. We've got ssh for that.
