Loading...
Loading...
Paste your private SSH keys securely. Zero-knowledge encryption ensures we cannot see your keys.
An SSH private key is not just a credential — it is an identity. Whoever holds the file becomes you on every server that trusts your authorized_keys entry. A leaked private key with no passphrase grants instant, persistent shell access; one with a passphrase grants the same access after a few hours of GPU-accelerated brute force on consumer hardware.
Modern keys come in several formats — RSA-2048 (legacy, still common), RSA-4096, ECDSA, and ed25519 — and each has its own header (-----BEGIN OPENSSH PRIVATE KEY-----, -----BEGIN RSA PRIVATE KEY-----). All of them are equally dangerous to mishandle. The format mostly affects the brute-force resistance of the passphrase, not the consequence of an unencrypted leak.
PasteOnce is well-suited to the narrow case where a private key genuinely has to move between machines — usually when you are provisioning your own access onto a fresh device, restoring after lost credentials, or briefly granting a contractor access to a single bastion host. For all other cases (especially adding access for someone else), share their public key, never your private one.
Client-side encrypted. We can't see your data.
Your data is encrypted in your browser before it leaves your device.
Messages are automatically deleted after being read once.
We never see your data. Only encrypted blobs pass through our servers.
Links work exactly once. Refresh the page and it's gone forever.
Your sensitive data is encrypted in your browser using AES-256-GCM. The encryption key is generated randomly and never sent to our servers.
Only the encrypted blob is stored in our database, with an automatic expiration time. We literally cannot read your data.
When your recipient opens the link, the encrypted data is fetched and immediately deleted from our servers using an atomic Redis GETDEL. The key in the URL hash decrypts the message in their browser.
ed25519 keys are smaller, faster, and resistant to side-channel attacks that affect older RSA implementations. Generate with 'ssh-keygen -t ed25519 -a 100' for a strong KDF on the passphrase.
A passphrase buys you hours of brute-force margin if the key file leaks. The OpenSSH default 16-round bcrypt KDF makes offline cracking measurably expensive on commodity GPUs.
In authorized_keys, prefix the entry with 'from="192.0.2.0/24",command="/usr/bin/restricted-shell"' to limit where the key works and what it can run, even if the key itself leaks.
Once the recipient confirms the key is working, generate a new key, push it to authorized_keys, and remove the old entry. The old key becomes useless within minutes.
A two-week contractor needs SSH into your jump host. You generate a new keypair specifically for them, paste the private key into PasteOnce, restrict the authorized_keys entry by source IP, and revoke the entry the day the contract ends.
Production is down at 2 AM and the senior with admin keys is offline. They paste a recovery key into PasteOnce from their phone, the on-call engineer reads it on their laptop, fixes the issue, and the key is rotated when the dust settles.
You are switching laptops and the old machine does not have rsync access to the new one. PasteOnce lets you transfer the encrypted key file between two browser sessions you control, without exposing it to a third party or cloud sync.
Only in narrow cases — provisioning your own key onto a new device, or restoring access during an incident. For everyone else's access, generate them a new keypair and only ever share the public key, or have them generate locally and send you their public key.
Yes — both. Run 'ssh-keygen -R hostname' to remove cached host keys and 'ssh-add -d ~/.ssh/old_key' to drop the rotated key from your local agent. Then audit ~/.ssh/authorized_keys on every machine that trusted the old key.
For granting someone access to your server, yes — they only need your public key in their authorized_keys. The case for sharing a private key is the inverse: you, or a system you fully control, need to prove a specific identity that already exists.
PasteOnce is text-only — base64-encode the zip if you must, but it is almost always better to share keys individually. The .ssh folder also typically contains known_hosts and config files that you do not need to leak alongside the key.