Designating Digital Rendezvous Points

Dec. 18, 2024 [technology] [guides] [libre]

Problem:

You deployed a remote system that you access at a site which you may not physically visit for weeks, months or even years at a time. But it does not have a static IP. An unexpectedly changed public IP address essentially puts us into the same dilemma as a parent losing track of a child. You want to preselect a known location where both parties will rendezvous in the event of separation.

The “normal” solution:

A corporate IT professional might be quick to recommend dynamic DNS, or to setup a job that emails the administrator (you) upon network changes. But these things often require some form of rent payment, increase complexity and inform intermediaries of things we’d rather they not see (especially if we’re freeloading on their services, more on that later).

The constraints at play:

• Being a private remote system that is only used by you, the IP address is sensitive information. Assigning a DNS record would expose this address.
• Configuring a dedicated email account for the remote system’s mail transfer agent brings problems - using an established email provider either costs money or complicates/prohibits the use of mail clients, while a smaller email service cannot be relied upon to continue its own existence.
• Use as few intermediaries as possible. Email would often mean two points of exchange between you and the remote system, unless both use the same email provider.
• Your local public IP also changes and so cannot be relied on for remote systems to reach out to automatically.
• Avoid sending alerts to the predetermined location in plain text. Message encryption is a must.
• Avoid creating new monthly bills to be paid.

With all that in mind, we’re going to do things the wrongthink way. And one of the perfect places to be used as a rendezvous point is any major Mastodon instance. Even though the microblogging format promotes idiotic human exchanges, it is the perfect place for short message passing by automated accounts. First, let’s setup a Mastodon bot:

1. Create a profile at any major Mastodon instance, sign in and navigate to the “<development>” tag in profile settings (bottem left as of 2024). The direct URL should be something like: https://fosstodon.org/settings/applications

2. Click the blue “New Application” button. Or use the direct URL: https://fosstodon.org/settings/applications/new

3. Give the application a name and check off the “write:statuses” option box.

4. Submit the form and return to your applications page. Then open the newly created profile and note the access token “Your access token: jY8tpxFTkQ8NZyaOy3rCaopKl2gKHZ51boVXBTGwUdh”.

The account is now ready to receive posts programmatically from cURL.

curl https://fosstodon.org/api/v1/statuses -H 'Authorization: Bearer jY8tpxFTkQ8NZyaOy3rCaopKl2gKHZ51boVXBTGwUdh' -F 'status=This post was made using the Mastodon API.'

The Authorization field is where you supply the access token that only you should ever see.

Next, we want to write a script that checks the remote host’s public IP address, compares it to the last known state and sends an update over Mastodon with any new IP address. Here is the script I devised (Requires curl, gpg and dnsutils be installed):

main(){
if [ ! -f /home/$USER/known.txt ]; then
        getip
	echo "Debug: Creating record!"
        writeip
else
        getip
        if [ "$current" != "$(cat /home/$USER/known.txt)" ]; then
		echo "Debug: IP address has changed!"
                message=$(echo "IP address has changed to $current" | gpg --batch --passphrase my-super-secure-passphrase --symmetric --armor)
		echo "Debug: $message"
                curl https://fosstodon.org/api/v1/statuses -H 'Authorization: Bearer jY8tpxFTkQ8NZyaOy3rCaopKl2gKHZ51boVXBTGwUdh' -F "status=$message"
                writeip
	else
		echo "Debug: IP address has not changed."
        fi
fi
exit 0
}

getip(){
current=$(dig -4 +short myip.opendns.com @resolver1.opendns.com)
if [ -n "$current" ]; then
        echo "Debug: Got an IP address from resolver successfully."
else
        echo "Debug: No IP address returned from resolver. Is network down?"
        exit 1
fi
}

writeip(){
echo "$current" > /home/$USER/known.txt
}

main

Notably, it uses gpg to symmetrically encrypt the actual message containing the IP address. That way other Mastodon users will only see some block of indecipherable text in the toot:

—–BEGIN PGP MESSAGE—–

jA0ECQMCphzIrBCs1iz60lwBGFccBsQUg5fkpUeovno0ZUsXW8U3xlBYRGtWroAp
zRFO5km97WAtJ0EXgbOVvmllz+PdgwkqCOtMLnjSm07KvD+rOsniMCa+GM/cWV+e
037uU25kyWOTDufN6w==
=ZvZP
—–END PGP MESSAGE—–

The reason we don’t use asymmetric keys is that it can inform observers of target email addresses (which is fine in a normal email exchange, which gpg is intended for). So remember to note whichever passphrase you write into the script somewhere on your side so that you can later decrypt this message passing when the need arises.

If it is the first time being run, this script will create a known record of the public IP address at the user’s $HOME. Changed IPs update this known record so that the Mastodon bot doesn’t end up spamming the same message.

Simply point cron to the script and setup a daily job. As a remote system, we can assume it will be powered on 24/7, thus no need for anacron.

crontab -e

15 12 * * * /home/name/address-watcher.sh

Now, on your end, whenever you find that you can no longer reach the target system, the first place to check is that public Mastodon bot. Has it tooted any PGP messages?