Security

    How to share SSH credentials with a link that expires securely

    Prefer the recipient's public key. When a private key or password must move, send it as a one-time link that expires and send the host and username separately.

    LinkPilot Team · The people who build and run LinkPilot at TetraCore, LLC · About LinkPilot

    Someone needs to get onto a server tonight, and the credential has to reach them now. The temptation is to paste the private key or the root password into Slack. Every message that key passes through keeps a copy, which is why the better route is a one-time link that expires: the secret is retrieved once and then it is gone.

    A link is only the delivery step, though. Before you create one, pick the right credential to send, scope it to the task and decide how you will remove it. This guide covers all of that, and includes the question of what to put in a one-time link for sharing server access details and what to leave out.

    Which SSH credential are you actually sharing?

    SSH access can rest on four different things, and they have very different sharing rules.

    | Credential | What it is | Should it ever move? | | --- | --- | --- | | Public key | The half the server stores | Yes, freely. It is not secret. | | Private key | The half the user holds | Only when generated for the recipient, and only once | | Password | A shared string checked by the server | Once, as a temporary value you will change | | SSH certificate | A key signed by your CA with a validity period | The certificate is not secret, the key behind it is |

    The best handoff is one where nothing secret moves. If the recipient already has an SSH key pair, ask for their public key, add it to ~/.ssh/authorized_keys on the right account, and tell them to connect. Removing that one line later ends their access.

    Generate a dedicated key for them when they do not have one and cannot make one. Never send your own everyday private key. A key made for the recipient can be scoped, logged and deleted without touching anything else.

    Prefer certificates or managed access for recurring needs. If the same person will need access repeatedly, repeated one-time handoffs are the wrong tool. An SSH certificate with a short validity, or an access tool such as Teleport or Tailscale SSH, gives you expiry built into the credential rather than bolted onto the delivery.

    Scope the credential before you share it

    Whatever you send, make it as small as the task allows:

    • One account, one host. Add the key to the service account that owns the work, not to root, and only on the machine involved.
    • Restrict what the key can do with authorized_keys options such as from="203.0.113.5", no-port-forwarding or a command= wrapper where the job is a single script.
    • Give the password a shelf life. If you are sharing a password, set passwd -e or the platform's equivalent so the recipient has to change it on first login, and plan to disable the account at a set date.
    • Write the end date down before you send anything. "When the work is done" is not a date.
    1. Confirm the recipient through a channel you already trust: the ticket, a known email thread, or a call. Most misdirected credentials are the result of a lookalike address or an autofilled name.
    2. Paste only the secret into the one-time secret link tool. For a private key that means the whole PEM block and nothing else. With LinkPilot the text is encrypted in your browser before it is stored, so the service only ever holds ciphertext, and the key to decrypt it sits in the part of the URL that browsers do not send to servers.
    3. Set the expiry to match the window. One hour if they are waiting for it, 24 hours if they are in another time zone, seven days only when there is a real reason. The link is also destroyed the first time it is opened, so expiry is the backstop, not the main control.
    4. Add a passphrase on a Pro account when the credential is sensitive, and pass the passphrase on by a different channel. An audit timeline on Pro also shows you when the reveal happened.
    5. Send the link with a one-line purpose note and no connection details.
    6. Send the connection details in a separate message: host or address, port, username, and the authentication method. None of those is secret alone, but together with the key they are the whole login.

    If the link reports that it has already been opened and the recipient says they did not open it, do not debate it. Treat the credential as exposed, remove the key or change the password, and generate a new one.

    The question of what belongs inside the secret comes up every time. A good rule is that the link carries the thing an attacker could not guess, and the plain message carries the things they could.

    In the one-time link:

    • The private key, or the temporary password
    • A passphrase for the key if one was set at generation time
    • Nothing else

    In a normal message, sent separately:

    • Hostname or IP address and port
    • The account to log in as
    • Whether to use a key or a password
    • The host key fingerprint, so the recipient can verify the server on first connection
    • A short note on what the access is for and when it ends

    Keep screenshots and terminal logs out of both. A screenshot of a working session often includes tokens, internal addresses and other usernames that were never meant to travel.

    Help the recipient land the key safely

    A secure handoff still fails if the key ends up in Downloads with world-readable permissions. Send these instructions along with the connection details:

    # save the key, then lock it down
chmod 600 ~/.ssh/acme_deploy
ssh-add ~/.ssh/acme_deploy
# verify the host key fingerprint against the one you were sent
ssh -i ~/.ssh/acme_deploy deploy@203.0.113.5

    Ask them to open the secret link only when they are ready to use it, on a device they control and over a connection they trust. Opening it on a shared machine "to check it works" leaves a copy in that machine's clipboard history.

    Verify, then close the window

    While the access window is still open, have the recipient test the exact connection and confirm the task runs. Do not widen the permissions to make a test pass; fix the scope instead.

    When the work is finished:

    1. Remove the public key from authorized_keys, or disable the account, or let the certificate expire on schedule.
    2. Rotate anything that travelled alongside the credential, including a temporary password that was meant to be changed on first login and was not.
    3. Review auth.log or your SSH audit source for connections outside the agreed time or from unexpected addresses.
    4. Write down who had what, from when to when. The record stays; the credential does not.

    Expiry on the link limits how long the secret could be retrieved. Expiry on the credential limits how long it can be used. You want both, and the second one is the one people forget.

    Tools for this article

    Frequently asked questions

    LinkPilot sends a secret link that is gone after it is opened.

    Encrypted in your browser, revealed once, then destroyed. No account needed.

    Create a secret link

    Read next