SSH support in Scriptable

I’ve been playing with SSH quite a bit recently, mostly using a Shortcuts cut.

One of the problems is that the SSH connection can’t stay open between calls to this cut. So I can’t issue a command and parse the results, before going again with another command. And so on.

So, I wonder if Scriptable could learn SSH. There is a thing called Paramikojs, which I haven’t played with. It sounds like it’s similar to the Paramiko Python library.

Out of interest, what sort of parsing are you thinking of doing that wouldn’t be manageable by the script running on the server side or that would be less manual so as to make using an SSH client app less preferable?

@sylumer I might’ve ought to of :slight_smile: said “grok”. :slight_smile:

I have nothing specific but if I open a session with something I’d like to have my code issue a command to the server, get the response back and tailor the next command based on that. And so on.

At its simplest a SSH “shell” - like Prompt - but more sophisticated as I could put client side javascript logic between the SSH commands.

The current Shortcuts behaviour, so far as I know, closes the session between each SSH action.

If I drive that from Drafts (and I have code to do that) the best I can hope for is to tailor a stream of commands BEFORE sending the stream to my helper Shortcuts cut that contains the SSH action.

Session persistence (in Shortcuts) isn’t something I’d see anything supporting until (if ever) there are full handshake inter app communications on iOS. If you really wanted persistence, then switching into a background terminal process you leave running each time you initiate a connection might be something you could explore? For example, there are some options listed here.

The premise of mixing server side instructions and client side processing in an ongoing interaction still seems odd to me without an example to hang it off. I’m struggling to envisage something that could be coded on the iOS side that couldn’t be coded on the server side, as anything device specific could be passed in an initial data payload and interactions with the user could potentially be handled by the script. It might not be in JavaScript, but given the plethora of languages that could potentially be available to be called upon on the server-side, that doesn’t sound like an issue, but more an opportunity.

But that"s not to say there isn’t value and a good use case here. Only that I’ve not got my head around one yet :face_with_raised_eyebrow:

1 Like