If you're on iOS, you can create a Shortcut that runs a script over SSH. I'm not sure if it's one of the native actions, or provided by an app called "Actions" which you can download from the App Store and which defines a bunch of useful actions.
Just looking at it on my phone, you need to "enable scripting" in Settings > Shortcuts > Advanced. Then when you add the shortcut, you can select password authentication or SSH Key. If you use a key, it generates one for you, and there is a button to "copy public key" which you'll then need to add to authorized_keys on your server. I assume the private key is stored locally on the device.
I've tried from a bunch of different phones to use RDP, and apart from launching some SW/service or run a batch, I just cannot without the pixels/screen. It's just too darn small. I wonder what smartphones you got.. some phablet with 7"-8" or a typical 6"-6.4"?
It had a slide-out keyboard which I loved. I would even write code remotely to fix a critical bug, and deploy it, while I was out having lunch with my team. No need to rush back to the office. Granted, I had better eyesight 20 years ago, but now I just use readers, can see the screen just fine.
I mean IMHO RDP has too many vulnerabilities too often to have it exposed to any network your phone also can promiscuously join. I would far rather expose a simple HTTP API for limited actions I consider safe.
Behind a VPN is fine, at least for personal use. At work, phones are never able to get on the same network as our servers though, and considering the random nature of apps people often install, my recommendation would be that they should not.
An underrated advantage of ChromeOS is easily running mobile apps that expose intuitive UI like this. Combined with the floating window mode I have enjoyed using bambu handy for 3d printing and vSphere mobile.
1. One that’s privileged for the shutdown command.
2. One with no privileges to accept the network request (eg Flask/REST), safely parse it, and send a message to process 1.
You could send the message in many ways. It doesn’t even have to be parsed or contain more than one byte. The reboot process might act if it receives any message from the other process in their dedicated channel.
Set both of these processes to run on startup however you normally do on your system.
If not a message, you could have the network enabled process write to a file in a shared directory. The reboot process periodically checks for the file’s existence. If it sees it, then it reboots the system. That file can be cleared on startup. I say on startup to reduce the risk of any kind of contention causing a problem later on.
The reboot process could also be easily ported to a systems language for resource efficiency. I’d keep the network-facing app in a memory-safe language just in case. D or Rust could handle both, though.
Yes of course, the spec can be implemented in any language. I've used Go mainly for personal preferences and portability with only one binary to scp on the server.
I'm going to try to propose other implementations as you suggest.
After one of my AWS accounts (with 2fa and an email I basically never used) was compromised I'm incredibly careful to expose services like this onto the public internet. What steps did you take to ensure the pipeline of your app to server endpoints was secure and in theory not vulnerable to someone traulling open ssh ports etc?
You could put it behind a Wireguard VPN.
That way you aren't exposing SSH or the like directly on the internet.
Properly-configured SSH with public key authentication is not something I worry about though.
I think the correct term here would be "on-premises".
A premise and a premises are not related concepts except in the sense that the "premise" of this comment is to let you know that "premises" is the correct term to use.
I'll also accept "on-prem" because it could reasonably be a shortened form of "on-premises" (even though most people probably don't realize this and are instead reinforcing their misconception when they use it).
You're absolutely right. The fun thing is that I googled it and saw a couple of articles doing the comparison between both. And to be honest, that's why I used the "on-prem" shortcut most of the time.
I think it's very complicated and I'm not sure what it does, or why it has a go http server and calls itself a specification.
But it's clear that your goal is to reboot on-prem servers through your phone. Something I've wanted to do with rundeck and a very simple web app that uses the rundeck API.
The Go HTTP server is an implementation of the spec (swagger.json). It actually plays the same role as your web app. It's just to make it compatible with the native app, and not rely on Web.
How happy are you with that setup? Would you use it for anything more complicated, like app deployments or maintenance tasks on your on prem / vpss?
I'm using ansible right now, and a custom playbook.sh script for some sort of auditing - what was run where and by whom. Kinda works but much more maintenable than let's say ansible tower.
There is probably no amount of protections which are appropriate for using SMS to send commands to a server. It's not only unencrypted the entire trip but SIM-jacking and caller ID spoofing are all very well-worn exploit paths.
I can email my house, which is at least encrypted in transit, and then I stack an extra couple nonstandard abuses of email headers to validate the source, which all is impossible with SMS.
https://en.m.wikipedia.org/wiki/HTC_Wizard
It had a slide-out keyboard which I loved. I would even write code remotely to fix a critical bug, and deploy it, while I was out having lunch with my team. No need to rush back to the office. Granted, I had better eyesight 20 years ago, but now I just use readers, can see the screen just fine.
Some random HTTP solution is the last thing I would trust.
https://www.tutorialspoint.com/python-script-to-restart-comp...
You can also use two scripts for security:
1. One that’s privileged for the shutdown command.
2. One with no privileges to accept the network request (eg Flask/REST), safely parse it, and send a message to process 1.
You could send the message in many ways. It doesn’t even have to be parsed or contain more than one byte. The reboot process might act if it receives any message from the other process in their dedicated channel.
Set both of these processes to run on startup however you normally do on your system.
If not a message, you could have the network enabled process write to a file in a shared directory. The reboot process periodically checks for the file’s existence. If it sees it, then it reboots the system. That file can be cleared on startup. I say on startup to reduce the risk of any kind of contention causing a problem later on.
The reboot process could also be easily ported to a systems language for resource efficiency. I’d keep the network-facing app in a memory-safe language just in case. D or Rust could handle both, though.
What do you mean by "traulling open ssh ports" ?
Follow these steps : https://github.com/c100k/rebootx-on-prem/blob/master/.github...
And then :
(cd ./impl/http-server-go && GOARCH=amd64 GOOS=openbsd go build -o rebootx-on-prem-http-server-go-openbsd-amd64 -v)
By adapting the arch if needed. Not tested, but it should work.
Sharing my current use case in case it's useful:
reboot PARTITION: to reboot to a different partition
systemctl stopping a service and starting another
launching a wget checking if wget is still up and hasn't crashed
I think the correct term here would be "on-premises".
A premise and a premises are not related concepts except in the sense that the "premise" of this comment is to let you know that "premises" is the correct term to use.
I'll also accept "on-prem" because it could reasonably be a shortened form of "on-premises" (even though most people probably don't realize this and are instead reinforcing their misconception when they use it).
But it's clear that your goal is to reboot on-prem servers through your phone. Something I've wanted to do with rundeck and a very simple web app that uses the rundeck API.
I'm using ansible right now, and a custom playbook.sh script for some sort of auditing - what was run where and by whom. Kinda works but much more maintenable than let's say ansible tower.
Should be very possible though, Rundeck has Ansible integration and with Ansible playbooks you do anything.
So all your custom website has to do is provide buttons for those pre-defined Ansible playbooks in rundeck.
I can email my house, which is at least encrypted in transit, and then I stack an extra couple nonstandard abuses of email headers to validate the source, which all is impossible with SMS.