Encrypt and Share Files Safely with pbputs

pbputs is the encrypted sibling of pbput: same paste-and-share idea, but nothing leaves your machine unencrypted first. The receiver uses pbget to recover it on the other end. This guide describes the installed pastebinit package, version 1.6.2-1, and its local pbputs(1) manual page.

Allow about fifteen minutes, plus whatever time it takes to agree a passphrase or line up a GPG key. You need a shell, the pastebinit package, and either a shared passphrase or a recipient key already in your GPG keyring. These examples upload to the default paste service, so swap in your own values and strip out any secret you did not mean to share before you actually run them.

1. Check the installed command

Confirm the executable and package version first. Both are ordinary, read-only commands that need no elevated privileges:

$ command -v pbputs
/usr/bin/pbputs
$ dpkg-query -W -f='${Package} ${Version}\n' pastebinit
pastebinit 1.6.2-1

The manual documents no general option parser for pbputs. Its interface is just a possible input filename followed by a possible GPG user: do not borrow flags from some unrelated paste client and assume they apply here.

2. Encrypt one file with a passphrase

For a file that does not need public-key juggling, pass its path and answer the prompt interactively:

$ pbputs ./REPORT_FILE
Enter passphrase:
http://pastebin.com/PASTE_ID

Swap in a real path for REPORT_FILE. The command compresses, encrypts and base64-encodes the data before it ever leaves your machine: LZMA compression, GPG encryption, and a paste service at http://pastebin.com by default. The URL is what your recipient needs for retrieval, the passphrase is a separate secret that has to reach them through a channel you actually trust.

Do not put the passphrase on the command line. Command lines can end up in shell history, process listings, or logs. If the file holds credentials, private keys or personal data, check the path carefully before you press enter. An encrypted upload is still an upload to a third-party service, and this command gives you no local copy of the remote paste afterwards.

3. Encrypt for a GPG recipient

When the recipient already has a usable public key in your keyring, give the GPG user as the second argument:

$ pbputs ./REPORT_FILE RECIPIENT_KEY
http://pastebin.com/PASTE_ID

Use whatever identifier your local GPG keyring accepts, an email identity or a fingerprint, and verify it actually selects the key you intend before uploading anything. The documented behaviour is to sign and encrypt to that recipient, who decrypts with their own private key, so you never have to transmit a shared passphrase at all.

This mode will not discover or create keys for you. If GPG reports an ambiguous, missing or untrusted key, stop and sort that out separately rather than guessing an email address and pushing a sensitive file through anyway.

4. Send standard input

To encrypt text or another command's output, pipe it straight to pbputs. There is no filename argument when the input arrives this way:

$ printf '%s\n' 'MESSAGE_FOR_RECIPIENT' | pbputs
Enter passphrase:
http://pastebin.com/PASTE_ID

For recipient encryption, put the GPG user right after the command in the pipeline:

$ some-command --report | pbputs RECIPIENT_KEY
http://pastebin.com/PASTE_ID

The manual draws a real distinction here: standard input is pasted back directly on recovery, while a named file or directory gets archived with tar first. That makes the pipeline handy for a quick report, but also easy to leak more output than you meant to. Check the producing command and its redirections before you run this.

5. Recover the upload with pbget

The recipient passes the returned URL to pbget. For a standard-input upload, recovery writes the plaintext straight to standard output:

$ pbget http://pastebin.com/PASTE_ID
MESSAGE_FOR_RECIPIENT

pbget asks for the shared passphrase when that was how you encrypted it. For GPG-recipient encryption, their own GPG setup supplies the private key needed to decrypt. Keep the URL and the secret travelling separately when you send them to someone else.

For a file or directory upload, give a destination directory when you want the archive extracted there directly:

$ mkdir -m 700 ./RECOVERY_DIR
$ pbget http://pastebin.com/PASTE_ID ./RECOVERY_DIR
INFO: Output is in [./RECOVERY_DIR]

Use a new, empty directory for an archive you have not seen before. Extraction can create paths and restore file attributes from inside the archive, so check the result before moving anything into a live configuration directory. Leave off the destination and the command builds one with mktemp instead, so make a note of the reported location if you will need to inspect it later.

6. Diagnose the common mistakes

A passphrase prompt is normal whenever no GPG recipient was supplied. A missing or wrong passphrase just means the recipient cannot decrypt: rerun the upload with the intended secret rather than putting a passphrase on the command line.

If a file cannot be found, check the path and your current directory without reaching for sudo:

$ pwd
$ test -r ./REPORT_FILE && printf '%s\n' 'input is readable'
input is readable

Elevated privileges are not part of the normal workflow here. Use them only when the source genuinely needs privileged read access, and remember that root can expose far more data than the report you actually wanted. Never use pbputs /etc/shadow as a test: that example in the manual is a warning about capability, not a safe thing to try.

If recovery fails, hold onto the URL, confirm whether the upload used a passphrase or a GPG recipient, and retry with the matching method. For an extracted archive, use a disposable destination and remove only that test directory once you have checked it. Do not delete the original input or overwrite an existing recovery directory while you are still troubleshooting.