Solved Shell Script IPC/RPC Messaging Between Different Hosts?



Reaction score: 19
Messages: 33

I would like one of my hosts to broadcast occasional periodic signals to a shell script running on other host(s) on the same LAN.

I'm currently reading about various IoT protocols, but I'm wondering what the more traditional approaches were for this kind of messaging.

Ideally, I'd want some kind of key verification to detect and ignore spoofed messages, but perhaps that's not critical for a home network.

I suppose I could just let the "sender" log in over SSH and run a restricted set of commands directly on the "receiver," but are there other ways to do this?


Well-Known Member

Reaction score: 259
Messages: 494

There's probably a lot of ways to do this, and I don't know about the traditional way.

I'd probably just use an http listener (e.g. Tcl httpd or Python or whatever equivalent) on the main server, and then get the clients to send http requests to it as simply as possible (e.g. curl or wget or whatever.)

On the server I could check the connecting IPs match my expected clients (or if on a LAN, any local IP).

But http etc probably a fairly "heavy" way of doing this (quick to set-up, though!), so could use your own protocol, but then more gubbins to deal with.


Well-Known Member

Reaction score: 37
Messages: 344

We build a control panel for webhosting using laravel that connects to other servers using SSH to run commands. It works very good.


Son of Beastie

Reaction score: 2,010
Messages: 2,963

I use ssh commands for the writing part of it: ssh to the other machine to run a small script, which leaves information in a file.

For reading, have the other machine keep the information in a web server, and read it with wget or curl.



Reaction score: 1,641
Messages: 2,466

A very simple tool provided by the base FreeBSD install is nc (NetCat).

To listen:

nc -l 1987

To send:

nc myhost 1987

So just listen in a loop for messages and that output can be redirected into shell script variables, etc.

MYVAR="$(nc -l 1987)"

If you want more security, then you can pipe things through OpenSSL (I think OpenSSL even provides an equivalent of netcat). However then SSH is a pretty nice choice (and again, in the base system so no pesky dependencies).


Well-Known Member

Reaction score: 144
Messages: 408

I think that the best approach depends a lot on how much custom code you need to execute when dealing with the "signal".

As others have suggested, ssh(1) and nc(1) are great building blocks.

I find perl(1) a powerful and easy tool for writing quick network connected tools. There's plenty of examples if you google "perl socket programming".

Another approach I use to achieve a specific action is ssh(1) login using a "one shot" key, e.g. on my FreeBSD host ritz:
[ritz.998] # cat /home/shutdown/.ssh/authorized_keys
# This login used in conjunction with the CyberGuard pwrstatd daemon on orac
# which activates /etc/ and /etc/
# The user "shutdown@orac" may use the ssh key below to initiate shutdown.
# To shutdown the host ritz form orac: "sudo -u shutdown ssh -n ritz"
# The user shutdown on this host must have sudo with no password required.
command="/usr/local/bin/sudo /sbin/shutdown -p now UPS powerfail",no-port-forwarding,no-x11-forwarding,no-agent-forwarding ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIHIN0FbajCxIgGnVij7P7tR1HNv7jSXJLp3JQOSVRBFj shutdown@orac
Every host on my network has a "shutdown" account, and on the host that runs the CyberGuard pwrstatd daemon, orac:
[orac.19628] # cat ~shutdown/.ssh/
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIHIN0FbajCxIgGnVij7P7tR1HNv7jSXJLp3JQOSVRBFj shutdown@orac

[orac.19631] # cat /etc/

# The UPS has raised an alarm (low battery or input power fail).
# Only physical systems sherman (ZFS storage), orac (KVM Virtualisation),
# pi3b, pi4, and the network switches that connect them have UPS power.
# There are also a number of virtual clients on orac (e.g. ritz).
# It's likely that everything on the network not connected to the UPS
# is already dead.  So we take care to avoid hanging.
# The zfs (NFS and iSCSI) server sherman should be last on the PEERS list.
# But, if you put orac on the PEERS list, make sure it's last.
# If you don't put orac in the PEERS list, pwrstatd will shut it down.

export PATH

PEERS="ritz fable mith sherman"

logtag=`basename $0`
for host in $PEERS
    ping -c1 -W1 $host
    if [ $? -ne 0 ]
        logger -p 'local0.notice' -t "$logtag" "UPS alert: skipping $host (not up)"
        logger -p 'local0.notice' -t "$logtag" "UPS alert: shutting down $host"
        sudo -u shutdown ssh -n shutdown@$host
done >/dev/null 2>&1



Reaction score: 19
Messages: 33

Thanks for the advice, everybody:
  • ssh with a dedicated user for simple one-shot events
  • nc over an ssh tunnel for more continuous event streams
  • curl to poll data from a simple web server if needed
  • write something in a better language for more complex needs



Reaction score: 1,641
Messages: 2,466

Thanks for the advice, everybody:
  • ssh with a dedicated user for simple one-shot events
  • nc over an ssh tunnel for more continuous event streams
  • curl to poll data from a simple web server if needed
  • write something in a better language for more complex needs
Oh, one more to add could be to leverage inetd. It basically runs any program (C, awk, sh, etc) but redirects stdin, stdout to a network stream. So you could write your program / test it via the command prompt and then hook it up to inetd to listen / respond to events.

Again, in the base system. Most UNIX-like platforms provide this.



Reaction score: 600
Messages: 2,483

Other traditional approaches: mq, mqtt, remote syslog, and so on. The list gets long after a while.
One of the many monitoring systems (you know, an "agent" on the client that reports data periodically to a central server) - there are many of those too.
For configuration management: ansible, cfengine, chef, puppet, and on and on.

It all depends on what you want to do.