spiped

Search Azure Marketplace for spiped, select the SecureAnyCloud publisher, and select Create.

Configure the Network Security Group to allow TCP 8022 from your client networks and TCP 22 for administration. Leave the plaintext port 9022 closed. It is bound to loopback and is not meant to be reachable from the network.

RG="pipe-prod"; LOCATION="eastus"; VM_NAME="pipe1" IMAGE_URN="sac1647283583153:spiped-ubuntu-24-04:default:latest" SSH_KEY="$(cat ~/.ssh/id_rsa.pub)" az group create --name "$RG" --location "$LOCATION"
# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:spiped-ubuntu-24-04:default:latest
az vm create \
  --resource-group "$RG" --name "$VM_NAME" \
  --image "$IMAGE_URN" \
  --size Standard_B2s \
  --admin-username azureuser \
  --ssh-key-values "$SSH_KEY" \
  --public-ip-sku Standard
az vm open-port --resource-group "$RG" --name "$VM_NAME" --port 8022 --priority 1001
az vm open-port --resource-group "$RG" --name "$VM_NAME" --port 22 --priority 1002

On first boot, the image generates this VM's 256 bit key and writes it to /etc/spiped/spiped.key. It records the key's fingerprint and a transportable copy in /root/spiped-credentials.txt, and only then releases the two spiped units to start. This completes within a few seconds.

SSH in as azureuser and read the details:

sudo cat /root/spiped-credentials.txt

The file lists the key file, its SHA-256 fingerprint, a base64 copy you can carry to the client machine, and the two endpoints. Keep the file readable by root only. It is the one place the key exists in a form you can copy.

Both units run under systemd as the unprivileged spiped user. The ss output in the following commands confirms that the encrypted endpoint listens on all interfaces and the plaintext endpoint is bound to loopback only.

systemctl is-active spiped.service
systemctl is-active spiped-client.service ps -o user= -C spiped | sort -u | tr -d ' ' ss -tlnp | grep -E ':8022 |:9022 '

Expected output:

active active spiped LISTEN 0 10 127.0.0.1:9022 0.0.0.0:* users:(("spiped",pid=3406,fd=3)) LISTEN 0 10 0.0.0.0:8022 0.0.0.0:* users:(("spiped",pid=3405,fd=3))

Confirm the build version:

timeout 10 spiped -v </dev/null 2>&1

spiped 1.6.4

Note the </dev/null redirect. Both spiped and spipe read standard input as part of normal operation, so redirect it whenever you only probe the binary.

This check runs entirely on this one VM. The client side encrypts a connection to the local plaintext port and carries it to the server side, which decrypts it and hands it to the protected service. In the shipped configuration, the protected service is this VM's own SSH daemon, because it is always present. Its greeting arriving back through the pipe proves that the whole path works.

echo -n 'through the pipe : '; timeout 8 bash -c 'exec 3<>/dev/tcp/127.0.0.1/9022; head -1 <&3' 2>/dev/null || echo 'no response'

Expected output:

through the pipe : SSH-2.0-OpenSSH_9.6p1 Ubuntu-3ubuntu13.18

The service at the far end of the pipe produced that greeting. A real byte stream passed through encryption and decryption, which shows the pipe is carrying traffic rather than merely holding a port open.

The encrypted endpoint on 8022 authenticates its peer during the spiped handshake. A client that cannot prove it holds this VM's key is dropped before it reaches the protected service.

Run the following commands to test three cases. They run on the VM against loopback. From a remote client, replace 127.0.0.1 with the VM address.

WRONGKEY=$(mktemp); dd if=/dev/urandom bs=32 count=1 of="$WRONGKEY" status=none echo -n 'plaintext client : '; timeout 8 bash -c 'exec 3<>/dev/tcp/127.0.0.1/8022; head -c 64 <&3' 2>/dev/null | grep -aq 'SSH-2.0' && echo 'reached the protected service' || echo 'never reached the protected service' echo -n 'wrong key : '; { sleep 3; } | timeout 10 spipe -t '[127.0.0.1]:8022' -k "$WRONGKEY" 2>/dev/null | head -1 | grep . || echo 'never reached the protected service' echo -n 'this VM key : '; { sleep 3; } | timeout 10
sudo spipe -t '[127.0.0.1]:8022' -k /etc/spiped/spiped.key 2>/dev/null | head -1 | grep . || echo 'never reached the protected service' rm -f "$WRONGKEY"

Expected output:

plaintext client : never reached the protected service wrong key : never reached the protected service this VM key : SSH-2.0-OpenSSH_9.6p1 Ubuntu-3ubuntu13.18

A plaintext client does receive a few bytes, because the spiped server opens its handshake by sending a random value. The client gets no further. Without the key, it cannot compute the authentication code the server expects, so the connection is dropped and the protected service is never touched.

spipe is the one-shot client shipped alongside the daemon. It speaks the same protocol but pipes standard input and output instead of listening on a port, which makes it convenient for checks like these.

In production, the server side stays on this VM and the client side runs wherever your traffic originates. Install spiped on that machine, recreate the key file from the base64 copy in the credentials file, and run the client side pointing at this VM.

On the VM, print the two values you need:

sudo grep -E '^KEY_SHA256=|^KEY_B64=' /root/spiped-credentials.txt

On your own machine, recreate the key and confirm that it matches. Replace <vm-ip> with this VM's address, and paste the base64 value from the previous command.

echo '<paste the KEY_B64 value here>' | base64 -d > spiped.key chmod 0600 spiped.key sha256sum spiped.key spiped -e -s '[127.0.0.1]:8022' -t '[<vm-ip>]:8022' -k spiped.key & ssh -p 8022 azureuser@127.0.0.1

The fingerprint printed by sha256sum must match the KEY_SHA256 value from the VM. The last two commands start the client side and then connect to 127.0.0.1:8022 on your own machine. This reaches the protected service on the VM, with everything between the two hosts encrypted and authenticated.

Transfer the key over a channel you already trust, such as an existing SSH session or a secrets manager. Anyone who obtains the key can both use and impersonate the pipe.

spiped takes all of its settings as command-line arguments. This image supplies them from one short file, so you never have to edit a systemd unit. Print the active settings:

grep -vE '^\s*#|^\s*$' /etc/spiped/spiped.conf

Expected output:

SPIPED_SERVER_SOURCE=[0.0.0.0]:8022 SPIPED_SERVER_TARGET=[127.0.0.1]:22 SPIPED_CLIENT_SOURCE=[127.0.0.1]:9022 SPIPED_CLIENT_TARGET=[127.0.0.1]:8022 SPIPED_KEY=/etc/spiped/spiped.key SPIPED_MAX_CONNS=100 SPIPED_TIMEOUT=5

SPIPED_SERVER_TARGET is the service you are protecting. SPIPED_CLIENT_TARGET is where the client side sends encrypted traffic. Addresses use spiped's own format: [ip.v4.ad.dr]:port, host.name:port, or an absolute path to a UNIX socket.

To protect a service other than SSH, change SPIPED_SERVER_TARGET to its address and restart the server side. The backend can be on this VM or anywhere else your VM can reach.

For example, to protect a PostgreSQL server elsewhere in your virtual network, replace <private-ip> with that server's address:

sudo sed -i 's|^SPIPED_SERVER_TARGET=.*|SPIPED_SERVER_TARGET=[<private-ip>]:5432|' /etc/spiped/spiped.conf
sudo systemctl restart spiped

Clients then run the client side locally and connect to their own loopback port as if PostgreSQL were running there. Neither side needs to know it is talking through an encrypted pipe. The database keeps speaking its own plaintext protocol, and the untrusted network in between only carries authenticated ciphertext.

To run several pipes on one VM, copy /etc/systemd/system/spiped.service to a second unit with its own source port and target. Give the new unit its own EnvironmentFile.

No default, shared or built-in key exists. The credentials file is 0600 root:root. The key file is 0640 root:spiped, so only root and the service account can read it. The directory itself is 0750.

sudo stat -c 'file: %n perms: %a owner: %U:%G' /root/spiped-credentials.txt /etc/spiped/spiped.key /etc/spiped
sudo stat -c '%s bytes' /etc/spiped/spiped.key
sudo sed -E 's/^(KEY_SHA256=.{12}).*/\1********************/; s/^(KEY_B64=.{10}).*/\1**************************/' /root/spiped-credentials.txt | grep -E '^KEY_FILE=|^KEY_SHA256=|^KEY_B64='

Expected output:

file: /root/spiped-credentials.txt perms: 600 owner: root:root file: /etc/spiped/spiped.key perms: 640 owner: root:spiped file: /etc/spiped perms: 750 owner: root:spiped 32 bytes KEY_FILE=/etc/spiped/spiped.key KEY_SHA256=a79dbcb3c8c5******************** KEY_B64=HQZAO+M2uo**************************

The key is exactly 32 bytes, which is the 256 bits of entropy upstream requires. It was read from the kernel random source on this instance's first boot. The fingerprint above differs on your VM, because every VM has its own key.