Yopass on Ubuntu 24.04 on Azure User Guide

Overview

This guide covers the deployment and configuration of Yopass on Ubuntu 24.04 on Azure using cloudimg Azure Marketplace images. Yopass is an open source, self hosted service for sharing sensitive information securely and temporarily. A sender types a secret into the web interface, Yopass encrypts it in the browser and returns a one time link, and the recipient opens that link once to reveal the secret, after which it is permanently destroyed. Because encryption and decryption happen client side, the server, this image, and its storage only ever hold opaque ciphertext with a fixed expiry.

The image builds the latest stable Yopass release reproducibly from source at build time (the exact version and source commit are recorded in /opt/yopass/VERSION). The Yopass server runs as a single Go binary under systemd as the unprivileged yopass system user and binds to loopback only (127.0.0.1:1337). Secrets are held in memcached, also bound to loopback (127.0.0.1:11211), so ciphertext lives in memory with a hard time to live and nothing is written to disk. nginx is the sole network facing surface and terminates TLS on port 443, reverse proxying to Yopass.

Yopass is unauthenticated by design. It is a public secret sharing service: there is no admin login, no API key and no database password, so none is ever baked into the image. The only per instance secret material is the TLS private key, which is regenerated for this specific VM on first boot (its Subject Alternative Names include the VM public IP, hostname and 127.0.0.1). No key material is ever shared between instances.

What is included:

• The latest stable Yopass release, built from source and run under systemd as the unprivileged yopass system user

• The Yopass server bound to loopback only (127.0.0.1:1337) and memcached bound to loopback (127.0.0.1:11211) — neither is network exposed

• nginx terminating TLS on :443 and reverse proxying to Yopass, with HSTS and sensible security headers

• Port :80 returns a 301 redirect to HTTPS for every path except an unauthenticated /healthz endpoint (HTTP 200) for load balancer probes

• A self signed TLS certificate regenerated per VM on first boot (SAN includes the VM public IP + hostname) — replace it with your own CA signed certificate for production

• A built in one time self test at /opt/yopass/yopass-selftest.sh that proves the self destruct semantics end to end over TLS

• Ubuntu 24.04 LTS base with latest security patches applied at build time

• Azure Linux Agent for seamless cloud integration and SSH key injection

• 24/7 cloudimg support with guaranteed 24 hour response SLA

Prerequisites

• An Azure subscription with permission to deploy virtual machines

• An SSH key pair for administrative access to the VM as the azureuser account

• A Network Security Group allowing inbound TCP 443 (HTTPS) and 80 (redirect) from the networks that should reach the service, and 22 (SSH) from your management network only

• A recommended size of Standard_B2s or larger

Step 1: Deploy from the Azure Portal

1. Locate the Yopass on Ubuntu 24.04 LTS by cloudimg image in the Azure Marketplace and select Create.

2. Choose your subscription, resource group and region.

3. Select a VM size (Standard_B2s or larger) and provide your SSH public key for the azureuser account.

4. On the Networking tab, allow inbound 443 and 80 from your users, and restrict 22 to your management network.

5. Review and create. When the VM is running, browse to https://<your-public-ip>/.

Step 2: Deploy from the Azure CLI

You can deploy the same image from the Azure CLI. Replace the resource group, location and image URN as needed:

az vm create \
  --resource-group my-yopass-rg \
  --name yopass \
  --image <cloudimg-yopass-image-urn> \
  --size Standard_B2s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard
# then open the required ports
az vm open-port --resource-group my-yopass-rg --name yopass --port 443 --priority 1001
az vm open-port --resource-group my-yopass-rg --name yopass --port 80 --priority 1002

Step 3: Verify the Yopass, memcached and nginx services

SSH in as azureuser and confirm the three services are active and that Yopass and memcached are bound to loopback only, with nginx the only public listener:

sudo systemctl is-active yopass memcached nginx

ss -tln | grep -E ':1337 |:11211 |:80 |:443 '

You should see yopass-server on 127.0.0.1:1337 and memcached on 127.0.0.1:11211 (both loopback only), while nginx listens on 0.0.0.0:80 and 0.0.0.0:443.

Step 4: Open the Yopass web interface

Browse to https://<your-public-ip>/. Because the certificate is self signed and generated per VM, your browser will warn about the certificate the first time. Accept it (or install your own certificate, see Step 12). You are presented with the Encrypt message form: type or paste your secret, choose how long it should live, and keep One time download and Generate decryption key enabled for the standard one click flow.

Step 5: Share a secret and get a one time link

Select Encrypt Message. Yopass encrypts the secret in your browser and stores only the ciphertext, then shows a one click link you can share with the recipient. The banner reminds you that the secret can be downloaded only once, so you should not open the link yourself.

Step 6: Reveal the secret once

When the recipient opens the link, Yopass decrypts the secret in their browser and displays it, with a clear warning that it will not be accessible again. This is the single permitted view.

Step 7: Confirm the secret self destructs

Opening the same link a second time proves the one time guarantee: the secret has already been consumed and permanently deleted, so Yopass reports that it does not exist.

Step 8: Verify the one time semantics from the command line

The image ships a self test that proves the self destruct behaviour end to end over TLS. It creates a one time secret through the API, reads it once (HTTP 200), then reads it again (HTTP 404):

sudo /opt/yopass/yopass-selftest.sh

The expected output confirms the round trip: the first read returns 200 and the second returns 404.

Step 9: Confirm TLS and inspect the per instance certificate

Confirm that plain HTTP redirects to HTTPS, that the web UI answers over TLS, and inspect the per VM self signed certificate:

curl -s -o /dev/null -w '%{http_code} -> %{redirect_url}\n' http://127.0.0.1/

curl -sk -o /dev/null -w '%{http_code}\n' https://127.0.0.1/

sudo openssl x509 -in /etc/nginx/tls/yopass.crt -noout -subject -ext subjectAltName

Step 10: Check the baked version and appliance info

The exact Yopass version and source commit baked into the image, along with the per VM appliance details, are recorded on the VM:

cat /opt/yopass/VERSION

sudo cat /root/yopass-info.txt

Step 11: How the appliance is wired

• Yopass server — a single Go binary at /opt/yopass/yopass-server, run by yopass.service as the unprivileged yopass user, bound to 127.0.0.1:1337, serving both the API and the web frontend from /opt/yopass/public.

• memcached — memcached.service, bound to 127.0.0.1:11211, holding only ciphertext with a fixed time to live. Yopass requires memcached, so yopass.service declares a dependency on it.

• nginx — nginx.service, terminating TLS on :443 and reverse proxying to Yopass, redirecting :80 to HTTPS, and serving an unauthenticated /healthz for load balancer probes.

• First boot — yopass-firstboot.service runs once on first boot: it regenerates the per VM self signed TLS certificate, starts the services, proves the one time round trip, and writes /root/yopass-info.txt.

Step 12: Use your own domain and a trusted certificate (production)

The image ships a self signed certificate so it is secure out of the box, but browsers will warn on it. For production, point a DNS name at the VM and install a CA signed certificate. With your own domain you can obtain a free certificate from Let's Encrypt:

sudo apt-get update && sudo apt-get install -y certbot python3-certbot-nginx
sudo certbot --nginx -d <your-domain>

Certbot installs the certificate into nginx and sets up automatic renewal. Yopass generates share links from the host the browser used, so no application configuration change is needed when you move to your own domain.

Step 13: Managing the Yopass service

sudo systemctl restart yopass

sudo journalctl -u yopass.service --no-pager | tail -20

Adjust server options (for example the maximum secret length or forcing one time secrets) by editing the ExecStart line in /etc/systemd/system/yopass.service, then run sudo systemctl daemon-reload && sudo systemctl restart yopass.

Step 14: Security recommendations

• Restrict SSH. Allow inbound 22 only from your management network; keep 443 (and 80 for the redirect) open to your users.

• Install a trusted certificate. Replace the self signed certificate with a CA signed one (Step 12) so recipients are not trained to click through warnings.

• Keep secrets short lived. The shortest expiry that still works for your recipients gives the smallest window of exposure. One time download is on by default.

• Send the link and the key separately when using the short link form, so that intercepting one channel is not enough to reveal a secret.

• Keep the image updated. Unattended security upgrades remain enabled so the OS keeps receiving patches.

Step 15: Support and Licensing

Yopass is open source software distributed under the Apache License 2.0. This image bundles the upstream Yopass release unmodified; the licence and notice files are retained on the image under /opt/yopass/. cloudimg packaging, hardening and support are provided by cloudimg.

Deploy on Azure

Find this image on the Azure Marketplace and deploy it in minutes. See www.cloudimg.co.uk for the full catalogue.

Need Help?

cloudimg provides 24/7 support with a guaranteed 24 hour response SLA. Contact us through www.cloudimg.co.uk for deployment assistance, configuration help or any questions about this image.