Password Pusher 2.17.1

In the AWS Marketplace listing, choose Continue to Subscribe, then Continue to Configuration. Pick Password Pusher 2.17.1 on Ubuntu 24.04 as the software version, choose your Region, and select Launch through EC2. Choose m5.large, your key pair, and a security group as described above.

To launch with the AWS CLI instead, replace the values in angle brackets:

aws ec2 run-instances --image-id <ami-id-from-the-listing> --instance-type m5.large \
  --key-name <your-key-pair> --security-group-ids <your-security-group> --subnet-id <your-subnet> \
  --metadata-options HttpTokens=required,HttpEndpoint=enabled \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=password-pusher}]'

First boot takes about half a minute after the instance is running. It generates the keys and the certificate and prepares the database.

To make the instance use your own name from the start, put the name in /etc/sac/pwpush-domain.preset with user data (for example a cloud-init write_files entry). Otherwise, first boot uses the instance's public IP address (or its private address if it has no public one) and also serves its EC2 public DNS name.

On Ubuntu 24.04, the SSH user is ubuntu. Connect with your key pair:

ssh -i <your-key.pem> ubuntu@<public-ip>

The login message shows the address of the web app.

Confirm that the three long-running services are active:

systemctl is-active pwpush pwpush-worker nginx

active active active

The pwpush-firstboot service runs once, on the first boot, and shows inactive on every later boot.

Only SSH, HTTP and HTTPS are public. Password Pusher listens on the loopback address. Check the listening ports:

sudo ss -tln | grep -E ':(22|80|443|5100) '

LISTEN 0 511 0.0.0.0:80 0.0.0.0:* LISTEN 0 4096 0.0.0.0:22 0.0.0.0:* LISTEN 0 511 0.0.0.0:443 0.0.0.0:* LISTEN 0 1024 127.0.0.1:5100 0.0.0.0:* LISTEN 0 511 [::]:80 [::]:* LISTEN 0 4096 [::]:22 [::]:* LISTEN 0 511 [::]:443 [::]:*

Then run the built-in self-test. It pushes a secret through nginx that may be viewed once, and reads it. It then checks that a second read finds the secret expired with no payload, and that its database row no longer holds the encrypted payload:

sudo pwpush-selftest

pwpush-selftest: created (1 view), first read 200 + identical payload, second read expired with no payload, database row emptied PWPUSH_SELFTEST_OK

Read the instance information file as root:

sudo cat /root/pwpush-info.txt

The file (root only, mode 0600) gives this instance's address, the SHA-256 fingerprint of its certificate, and the locations of the settings, the encryption key and the database. There is no administrator password to collect, because this Password Pusher has no accounts.

# Password Pusher 2.17.1 on this instance. Open the URL in a browser; there is no account or password (anonymous).
# The certificate is self-signed for this instance: compare its SHA-256 fingerprint with PWPUSH_TLS_SHA256 below.
# Pushes are encrypted with this instance's own key (/etc/pwpush/master.key): back it up with the database. PWPUSH_URL=https://198.51.100.24/ PWPUSH_HOST=198.51.100.24 PWPUSH_TLS_SHA256=CC:31:61:86:...:(64 hex digits in pairs) PWPUSH_ADDRESS_SOURCE=imdsv2-public-ipv4 PWPUSH_SETTINGS=/etc/pwpush/pwpush.env PWPUSH_MASTER_KEY_FILE=/etc/pwpush/master.key PWPUSH_DATABASE=/var/lib/pwpush/storage/db/production.sqlite3 GUIDE=https://secureanycloud.com/stacks/password-pusher-2-17-1/

The certificate is self-signed and unique to your instance, so your browser warns about it. Open the certificate details in the browser and check that its SHA-256 fingerprint matches PWPUSH_TLS_SHA256. Only then continue.

Do not add the certificate to your operating system's trust store. For production, replace it with a certificate from a certificate authority (Step 11). The certificate is an end-entity certificate for this instance's names only.

Copy the certificate to your home directory so that the commands in this guide can use it as their trust anchor:

sudo cat /etc/ssl/pwpush/pwpush.crt > ~/pwpush-instance.crt openssl x509 -in ~/pwpush-instance.crt -noout -subject -ext basicConstraints,keyUsage,extendedKeyUsage,subjectAltName

subject=CN = 198.51.100.24, O = sac X509v3 Subject Alternative Name: IP Address:198.51.100.24, DNS:ec2-198-51-100-24.compute-1.amazonaws.com, IP Address:172.31.16.20, IP Address:127.0.0.1 X509v3 Basic Constraints: critical CA:FALSE X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Server Authentication

Browse to the PWPUSH_URL address. Type or paste the secret, or use Generate Password. Use the sliders to choose how many days and how many views the link may last, whichever comes first (here 1 day and 1 view). The Qr Codes tab pushes text as a QR code instead.

The screenshots in this guide were taken on an instance set to the name pwpush.example.com (Step 11). Your instance shows its own address until you set a name:

Choose Push It!. The secret is encrypted with this instance's key and stored. The page shows the secret link with a copy button, a QR code of the link, a ready-to-send message that includes the link and its expiry, and the limits. Send the link to the recipient over any channel, and do not open it yourself:

The link ends in /r. It opens a retrieval step first, so a chat or email program that previews links does not use up a view. The recipient opens the link and confirms:

The recipient chooses Click Here to Proceed. The secret appears blurred until they click it, with Copy to Clipboard buttons and the time the link has left:

The one allowed view is now used up and the secret is deleted. Opening the same link again shows that it has expired. If a recipient sees this the first time they open a link, someone else has opened it:

Enter a passphrase in the Passphrase field when you push a secret, and send it to the recipient by a different channel from the link. The link then asks for the passphrase before anything is shown:

A wrong passphrase is refused with That passphrase is incorrect. The right passphrase shows the secret. While views are left (this push allowed 2), the recipient can delete the secret at once instead of waiting for it to expire:

Password Pusher asks the recipient to confirm. Delete removes the secret from the database, even though a view and a day were left, and the link shows that it has expired from then on:

Password Pusher has a JSON API. On the instance, connect to nginx on the loopback address with --connect-to, because the security group normally does not let an instance reach its own public address. Use the instance certificate as the trust anchor.

The following commands create a secret that lasts 1 day or 2 views, read it twice, and then read it a third time:

U=$(sudo sed -n 's/^PWPUSH_URL=//p' /root/pwpush-info.txt) jq -n --arg p 'api-test secret' '{password: {payload: $p, expire_after_days: 1, expire_after_views: 2}}' > ~/push.json
R=$(curl -s --cacert ~/pwpush-instance.crt --connect-to ::127.0.0.1:443 -H 'Content-Type: application/json' --data-binary @"$HOME/push.json" "${U}p.json")
echo "${R}" | jq -c '{html_url, expire_after_days, expire_after_views, expired}'
T=$(echo "${R}" | jq -r .url_token) for n in 1 2 3; do curl -s --cacert ~/pwpush-instance.crt --connect-to ::127.0.0.1:443 "${U}p/${T}.json" | jq -c '{payload, expired, views_remaining}'; done rm -f ~/push.json

{"html_url":"https://198.51.100.24/p/_buo1vuuuava6h0/r","expire_after_days":1,"expire_after_views":2,"expired":false} {"payload":"api-test secret","expired":false,"views_remaining":1} {"payload":"api-test secret","expired":false,"views_remaining":0} {"payload":null,"expired":true,"views_remaining":0}

html_url is the link to send. The response also carries url_token, the secret part of the link. Give the link to the recipient instead of reading the secret yourself, because every read through the API uses up a view, just as the page does.

Requests made by a page on another website are refused before they reach Password Pusher. Their Origin is not this instance, so nginx answers 403. A request for a host name the instance does not serve gets no answer at all (curl reports 000):

U=$(sudo sed -n 's/^PWPUSH_URL=//p' /root/pwpush-info.txt)
curl -s --cacert ~/pwpush-instance.crt --connect-to ::127.0.0.1:443 -o /dev/null -w '%{http_code}\n' -H 'Content-Type: application/json' \
  -H 'Origin: https://evil.example' --data '{"password":{"payload":"x"}}' "${U}p.json"
curl -s -k --connect-to ::127.0.0.1:443 -o /dev/null -w '%{http_code}\n' https://unknown.example/ || echo "(no answer: nginx closed the connection)"

403 000 (no answer: nginx closed the connection)

The appliance settings are in /etc/pwpush/pwpush.env (owned by root and the pwpush group, mode 0640). The file holds no secret:

sudo grep -E '^PWP__' /etc/pwpush/pwpush.env

PWP__DISABLE_LOGINS=true PWP__DISABLE_SIGNUPS=true PWP__ALLOW_ANONYMOUS=true PWP__ENABLE_URL_PUSHES=false PWP__ENABLE_FILE_PUSHES=false PWP__ENABLE_QR_PUSHES=true PWP__NOTIFY_BY_EMAIL__ENABLED=false PWP__PROMETHEUS__ENABLED=false PWP__CLOUDFLARE_PROXY=false PWP__HOST_PROTOCOL=https PWP__LOG_LEVEL=warn

nginx limits how fast one client address can create, unlock or delete secrets, and how many requests it can make in all. The address is the real TCP peer. A forged X-Forwarded-For header neither changes it nor appears in the log. Inspect the limits:

grep -E 'limit_req_zone' /etc/nginx/conf.d/sac-pwpush.conf
grep -E 'client_max_body_size|limit_req ' /etc/nginx/sites-available/pwpush

limit_req_zone $sac_pwpush_write_key zone=pwpush_write:10m rate=12r/m; limit_req_zone $binary_remote_addr zone=pwpush_all:10m rate=20r/s; client_max_body_size 2m; limit_req zone=pwpush_write burst=20 nodelay; limit_req zone=pwpush_all burst=100 nodelay;

A client over the limit gets HTTP 429 until its allowance refills. Other clients are not affected.

The access log records secret links without their tokens:

sudo tail -3 /var/log/nginx/access.log | sed -E 's/^[0-9a-f.:]+ /<client-ip> /'

<client-ip> - [08/Nov/2026:08:37:21 +0000] "GET /p/<token>.json HTTP/2.0" 200 474 "curl/8.5.0" <client-ip> - [08/Nov/2026:08:37:23 +0000] "POST /p.json HTTP/2.0" 403 146 "curl/8.5.0" <client-ip> - [08/Nov/2026:08:37:23 +0000] "GET / HTTP/2.0" 444 0 "curl/8.5.0"

Your security group decides who can create secret links. Keep the 443 and 80 rules limited to the networks that should use the service.

To put the service on a private address only, launch it in a private subnet (or remove the public IP) and allow 443 from your VPC CIDR or VPN range.

New pushes default to 7 days and 5 views, with the retrieval step on and the recipient allowed to delete the secret. A sender can choose up to 90 days and 100 views.

Password Pusher reads its settings from its own settings.yml. You can override any of them with a PWP__ line in /etc/pwpush/pwpush.env. The name is the setting's path in capitals, joined with __.

To see the settings Password Pusher is running with, run:

sudo pwpush-rails runner 'pw = Settings.pw; puts({days_default: pw.expire_after_days_default, days_max: pw.expire_after_days_max, views_default: pw.expire_after_views_default, views_max: pw.expire_after_views_max, retrieval_step: pw.retrieval_step_default, deletable_by_viewer: pw.deletable_pushes_default}.inspect)'

Password Pusher Version: 2.17.1 {days_default: 7, days_max: 90, views_default: 5, views_max: 100, retrieval_step: true, deletable_by_viewer: true}

For example, to make new pushes default to 1 day and 1 view (the sender can still choose more), run:

printf '%s\n' 'PWP__PW__EXPIRE_AFTER_DAYS_DEFAULT=1' 'PWP__PW__EXPIRE_AFTER_VIEWS_DEFAULT=1' | sudo tee -a /etc/pwpush/pwpush.env >/dev/null
sudo systemctl restart pwpush pwpush-worker

Every setting is described in /opt/pwpush/app/config/settings.yml.

Keep PWP__DISABLE_LOGINS, PWP__DISABLE_SIGNUPS and PWP__ALLOW_ANONYMOUS as they are. This image has no mail server for account sign-ups, and with logins on, Password Pusher starts a first-run administrator wizard that anyone who reaches the page first could complete.

URL pushes are off because an anonymous URL push lets anyone create a redirect from your domain to any site. If only trusted networks can reach the instance and you want URL pushes, enable them:

sudo sed -i 's/^PWP__ENABLE_URL_PUSHES=false$/PWP__ENABLE_URL_PUSHES=true/' /etc/pwpush/pwpush.env
sudo systemctl restart pwpush pwpush-worker

sudo pwpush-rails ARGS runs bin/rails ARGS as the pwpush user with these settings, for example sudo pwpush-rails runner 'puts Push.count'.

Secrets are stored in the SQLite database /var/lib/pwpush/storage/db/production.sqlite3, encrypted with the Lockbox key in /etc/pwpush/master.key. The Rails credentials (with this instance's secret_key_base) are in /opt/pwpush/app/config/credentials/.

Only the pwpush user can read the key files. Check the ownership and modes:

sudo stat -c '%a %U:%G %n' /etc/pwpush/master.key /etc/pwpush/pwpush.env /opt/pwpush/app/config/credentials/production.key \
  /opt/pwpush/app/config/credentials/production.yml.enc /var/lib/pwpush/storage/db/production.sqlite3

400 pwpush:pwpush /etc/pwpush/master.key 640 root:pwpush /etc/pwpush/pwpush.env 400 pwpush:pwpush /opt/pwpush/app/config/credentials/production.key 440 root:pwpush /opt/pwpush/app/config/credentials/production.yml.enc 600 pwpush:pwpush /var/lib/pwpush/storage/db/production.sqlite3

The database never holds a secret in plain text, so a copy of the database alone reveals nothing. A copy together with master.key reveals every secret that has not expired yet.

Keep master.key with your backups of the database, and protect both. Without the key, the stored secrets cannot be read.

To back up, stop the service briefly and copy both files. Replace <backup-dir> with a directory that only root can read:

sudo systemctl stop pwpush pwpush-worker
sudo install -d -m 0700 <backup-dir>
sudo cp -p /etc/pwpush/master.key /var/lib/pwpush/storage/db/production.sqlite3 <backup-dir>/
sudo systemctl start pwpush pwpush-worker

Secret links are short-lived by design, so many teams do not back up this service at all. If the instance is lost, senders push the secret again.

Point a DNS record (for example pwpush.example.com) at the instance. Then run the domain command with the new name first, followed by any other names or addresses that should keep working:

sudo pwpush-set-domain pwpush.example.com "$(sudo sed -n 's/^PWPUSH_HOST=//p' /root/pwpush-info.txt)"

nginx then serves only those names, and a new self-signed certificate is issued for them. /root/pwpush-info.txt shows the new address and fingerprint.

Secret links use the name the sender browsed to, so open Password Pusher at https://pwpush.example.com/. If you use the IP address rather than a DNS name, run pwpush-set-domain again whenever a stop and start changes the instance's public IP address.

To use a certificate from a certificate authority, first run pwpush-set-domain with your name. Then replace /etc/ssl/pwpush/pwpush.crt (full chain) and /etc/ssl/pwpush/pwpush.key (mode 0600, root), and run sudo systemctl reload nginx.

Running pwpush-set-domain again issues a new self-signed certificate, so put your certificate back after any later run.

• Metadata service. The AMI requires IMDSv2. Password Pusher and its worker may talk to the loopback address only, and systemd denies nginx and the first-boot service access to the instance metadata addresses. Password Pusher sends no mail and makes no outbound requests.

systemctl show -p IPAddressAllow -p IPAddressDeny pwpush pwpush-worker
systemctl show -p IPAddressDeny nginx pwpush-firstboot

IPAddressAllow=127.0.0.0/8 ::1/128 IPAddressDeny=0.0.0.0/0 ::/0 IPAddressAllow=127.0.0.0/8 ::1/128 IPAddressDeny=0.0.0.0/0 ::/0 IPAddressDeny=2001::/32 64:ff9b::/96 2002::/16 169.254.169.254/32 168.63.129.16/32 64:ff9b:1::/48 ::ffff:0.0.0.0/96 fd00:ec2::254/128 IPAddressDeny=64:ff9b:1::/48 64:ff9b::/96 2002::/16 168.63.129.16/32 2001::/32 169.254.169.254/32 ::ffff:0.0.0.0/96 fd00:ec2::254/128

• Where the keys live. Password Pusher reads its Lockbox key from /etc/pwpush/master.key (mode 0400, pwpush). The environment only names the file (PWPUSH_MASTER_KEY_FILE), so the key is in no process environment, command line, journal or log. The Rails credentials key is production.key (mode 0400, pwpush). All three keys are generated on your instance at first boot. Core dumps are off for Password Pusher and nginx, and the instance has no swap.
• Response headers. Every page is served with Password Pusher's own Content-Security-Policy, nginx's frame-ancestors 'none' policy, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Referrer-Policy: same-origin (a secret link is never sent to another site, and the page's own forms keep their Origin), Cross-Origin-Opener-Policy: same-origin and Strict-Transport-Security.
• Ruby gem security fixes. Password Pusher 2.17.1's own lock file pins Rails 8.1.4, which has published advisories, including a critical one in Active Storage. SecureAnyCloud updates the lock file inside 2.17.1's own version constraints (bundle lock --update --conservative): Rails 8.1.4.1, loofah 2.25.3, rails-html-sanitizer 1.7.2 and nokogiri 1.19.7. A scan of 2.17.1's original lock file finds 32 advisories, and a scan of the shipped lock file finds none. The exact change is in /usr/share/doc/sac-pwpush/gemfile-lock.diff. One advisory remains in the JavaScript build tools (minimatch, a denial of service through a crafted pattern). Those tools run only at build time, on the build's own files, and are not on the image.
• Upgrades. Ubuntu security updates (including nginx) install automatically. Password Pusher and its Ruby are built for this image, so SecureAnyCloud publishes new versions of this AMI for new Password Pusher releases and gem security fixes.

Password Pusher is licensed under the Apache License 2.0. The image ships its license and records exactly what it was built from. Print the build record and the Ruby version:

cat /usr/share/doc/sac-pwpush/SOURCE.txt /opt/pwpush/ruby/bin/ruby -v

Password Pusher 2.17.1 (Apache-2.0) source: https://github.com/pglombardo/PasswordPusher.git tag v2.17.1 = commit 6219d332864f4baecde7742e732231063b9a990a (pinned by tag and sha) license sha256: aa870dca9a9c4c65e745d961d15c01e53a0846db155995ad23fdcf5c698802a4 Gemfile.lock: the tag lock (sha256 18de9972a09779a8651d0b6ad3d96fa5cabeec6d4c74aaaef0b37124238ec1a5) + the sac in-range security raises (recipe file password-pusher-aws-gemfile-lock.diff, sha256 bdec351e9c54f163d4205ff558918fab5e3c15dc768185f4859a11478b6ec478) = sha256 f0d4288a3030b8cb363c458d9a3b47205793fd7ddc9b85d20d5c6f44020625e8 ruby: https://cache.ruby-lang.org/pub/ruby/4.0/ruby-4.0.9.tar.gz (sha256 c35350682ff050b79702d57ade4516e7336063f510155d19fb2fb5b3f3909511), compiled from source assets built with node v24.22.2 (sha256 48cc0e21e048790e54c0cf5749c2725005313d652651c40b7a21feb9697aaf75) + yarn 1.22.22 (sha256 c17d3797fb9a9115bf375e31bfd30058cac6bc9c3b8807a3d8cb2094794b51ca); neither ships ruby 4.0.9 (2026-10-23 revision 3e93b23afc) +PRISM [x86_64-linux]

SecureAnyCloud builds Password Pusher from the upstream v2.17.1 tag, pinned to its commit. Every download is checked against a fixed SHA-256, and Node.js is also checked against its signed checksum list. A different file stops the build.

The license text is in /usr/share/doc/sac-pwpush/LICENSE-PasswordPusher-Apache-2.0.txt. Ruby (Ruby license or BSD-2-Clause) and the gems keep their own licenses, and nginx is the Ubuntu package (/usr/share/doc/nginx/copyright).

Password Pusher is a trademark of its respective owner. All product and company names are trademarks or registered trademarks of their respective holders. SecureAnyCloud is not affiliated with or endorsed by them.