As someone who usually works with people in other countries it has always been a problem to send login information to each-other.

For development login details like debug databases etc sure I can send them over in clear text email or something but when it comes to actual production information such as SSH keys how do you securely send them to someone when face to face contact isn't possible.


14 Answers 14


I usually use SMS. While not perfectly secure, this is more secure than email and generally adequate. It has the major benefit of not requiring any setup, such as exchanging PGP keys.

You could make this more secure by sending half of the password by email and half by SMS. Alternatively (as suggested by Michael Kropat) send a file with the symmetrically encrypted password by email, and SMS the decryption password.

For SSH keys, you should only transfer the public key. If you're granting a user access to a server, they should send you their public key, rather than you send them a private key. You still need to confirm the received key is authentic, but you don't need to keep it confidential.

  • 1
    +1 for this. I also use sms for "secure" password transmission, while sending other information by other channels - email or IRC. Someone intercepting the message alone would not have enough information to find out what it is a password for. This is only valid security if the password is a one-time use pass, and the user is forced to change it on login, though.
    – Riot
    Commented May 22, 2014 at 14:26
  • 11
    I wouldn't just split the password. Encrypt the password text with something simple like openssl aes-256-cbc -out FILE, email the encrypted file to them, and then send the decryption password via SMS. Commented May 22, 2014 at 20:11
  • 1
    SMS is even better when you use something like TextSecure. Commented May 23, 2014 at 1:17
  • 1
    How about sending the password via a regular phone call? If that's not good enough, how about using something like Cellcrypt?
    – DJG
    Commented May 23, 2014 at 22:59
  • 1
    @Bergi - good question, and possibly worthy of a question in its own right. Traditionally because SMS had transport encryption and trustworthy operators. These days email tends to also have those properties, so the difference is somewhat less. In this case. the key benefit is SMS being a separate channel, allowing tricks like splitting the password in two.
    – paj28
    Commented May 29, 2014 at 19:03

When I need to send something a single time, I have used One Time Secret. It's an open-source web app that allows you to enter information that can only be viewed once. After the recipient has opened the page, the information is deleted, and the only thing remaining in your chat logs or email is a bad link.

It's not as robust as your entire team using PGP, but it's much easier to set up or explain. I've been able to use it to send login information to fairly non-technical people, and they find it easy to use.

  • 9
    This is an excellent solution if you don't mind someone else getting the password instead.
    – lily
    Commented May 22, 2014 at 17:42
  • 8
    @IstvanChung You could in theory not activate a key/password before the other end reports that they succesfully read/saved the key/password that was behind the link.
    – Sumurai8
    Commented May 22, 2014 at 17:48
  • 10
    @Keavon re: "Nobody will guess a link like ..." I'm not willing to trust to the security of this- among other things, this means I have to trust the admin of the server. re: "It also lets you password protect the info." Well, if I have a secure means of transmitting the password with which I'm protecting the info, then what's the point of this in the first place?
    – lily
    Commented May 23, 2014 at 4:03
  • 5
    @IstvanChung you can also host an instance of this service yourself since they have published the source.
    – JE42
    Commented May 25, 2014 at 8:00
  • 4
    I run OTS in an enterprise environment. It's great. We've reskinned it and locked it down on a minimal VM. Commented May 26, 2014 at 14:27

As has been said already in the comment, this is a classical use case for GPG/PGP. Everybody creates a key, you exchange them in an arbitrary way, and then you verify the fingerprints over the phone, a video chat or any other channel with reasonable protection against data tampering.

You can also sign each others' keys to create a small web of trust. For example, if you've already verified and signed the keys of developer A and developer B, then A and B can trust each other without having to verify the keys again.

  • 3
    Not to easy to use since some of the people I work with use services such as hotmail which don't have buildin GPG/PGP feature and you have to use a mail client to do it. Also some of the people I work with aren't that tech savy to know how to use GPG/PGP(Tho it is a good solution for developers).
    – user36976
    Commented May 22, 2014 at 12:43
  • 1
    Use the term "asimmetric key" instead of GPG/PGP. An SSH p2p connection or cripted chat or similar would do the job
    – Lesto
    Commented May 22, 2014 at 16:20
  • 4
    It's not just any form of asymmetric encryption. As stated above, one of the features of GPG is that users can sign keys and build a web of trust. This surely helps in team situations. The leading developer could verify and sign all keys once, and then everybody can communicate with everybody without having to personally verify the keys first. This isn't true for all protocols.
    – Fleche
    Commented May 22, 2014 at 17:49
  • @Nick It isn't necessary to have GPG/PGP built-in to your mail client. You can do the encryption and decryption using a stand-alone tool, then just send the ASCII-armored text through mail.
    – lily
    Commented May 25, 2014 at 23:33
  • 1
    I've trained clients to use PGP/GPG; any one competent (enough to be trusted with a password, to anything) picks it up fairly easily. But the bit that trips most people up is they forget their passphrase. I then have to explain there is no way to get it back and they have to start over again. Commented May 27, 2014 at 8:39

For SSH keys, I have them generate the key and send me the public key, then we can simply compare fingerprints over the phone.


You can use the slow method of mailing them (postal) the keys on a USB key but that in today's age is not practical. What I do in situations like this is, I have a dedicated NOC operations web server I use to store the keys in a directory I will create for whomever I need to send keys to. I lock down the webserver with mod_security and .htaccess rules to ONLY allow the individual I want seeing that directory (via IP).

My structure is something similar to the following. Suppose I need to create a key for say a dev group in China, I will make a directory based on the checksum of their name/group, etc:

[myoto@mymachine ~]# mkdir `md5 -s devchina | awk '{print $4}'` 
[myoto@mymachine ~]# cd `md5 -s devchina | awk '{print $4}'`
[myoto@mymachine ~/4b4dda9422c2de29f9a0364f1bd8494d]# cp /path/to/ssh_keys/what_I_want_2_copy .

This ensures no one can stumble upon a directory using something like Nikto/Wikto, etc. the .htaccess and mod_security rules enable me to control who gets to that directory, and I can clean it up after I see via logs, the keys have been copied.

  • Particularly if it's only for temporary use, why use a hash? Just make a GUID (mkdir -v $(uuidgen)), or take the number of nanoseconds since the second at this arbitrary point in time (mkdir -v $(date +%N)). Both will be pretty hard to just "stumble upon" in the short amount of time it exists if you clean it up afterwards.
    – user
    Commented May 24, 2014 at 19:34
  • @MichaelKjörling you are right, but does not scale well if you have a lot of these folder outstanding Commented Jul 9, 2015 at 13:41

You probably don't need to be sending ssh secret keys around.

The remote individual should generate a key pair on their end, keep the secret key, and send you the public key.

The public key isn't a secret, so it's not a problem to send it in the clear. Only the private key is secret, and that doesn't need to be transmitted because they already have it.

Then you just add their public key to the authorized keys list.

The only problem you might have is determining that the public key you received really is from the person you want to give access to.

If you have other secret information that you do need to share, well, now you both have secure access to shared server so you can use that.


If you both set up an account with LastPass, this service allows for you to share your passwords (and other secure information) with other parties.

  • 1
    Yeah, if you like giving whoever runs LastPass all your information. Third Party software for this is not a good solution unless you trust and know the person running the website, and even then the database could be broken into Commented Dec 16, 2016 at 17:31

If they each can setup an account with a secure file sharing site, you can share files to each of them. If you want to do it yourself, you can setup something like OwnCloud with encryption enabled and use that as a means of secure file exchange with multiple people as long as you use SSL for the OwnCloud instance and can make one secure credential distribution out of band.


The main problem about this is that we are sending passwords normally to simple users, who have problems to open a gpg-signed mail.

What the problem real worsened by that our job/wage/project depends on their judgement, how happy they are to co-working with us. Also our first priority is to make this password-thing as simple as possible for them. I am sorry to say that, but in the reality it is more important as to reduce the chance of a breakin from 0.1% to 0.01% in the next month.

Normally I do the following:

  • I send everything (username, additional login infos) in a simple, unencrypted mail, except the actual password,
  • I refer the actual password as "I sent this in SMS to you"
  • And I send an SMS concurrently with the mail, only with the simple password, without any comment.

There are a number of services which allow you to enter either plan text or HTML into a browser and generate a one time link to share via the relevant channel.

The basis is that you do not send sensitive data anywhere it's stored or processed as plain text!

These services are good because the link is a one time use, the data in transit and at rest is encrypted and without the right link it's garbage. They can also have the link sent via normal channels and can be accessed by anyone so makes for a much easier end user process.

Some examples are:

Full disclosure, Burn After Reading this is one of our products.


With PGP/GPG (and most other suggested answers) you have to solve the authentication problem to prevent man in the middle attacks. SMS should not be considered save, since GSM encryption has long been hacked.

I would use OTR (can't post more links, just google).

With some chat client, such as pidgin. You can then even use some unsecure channel, such as Facebook, Google chat, ICQ, what ever, establish an encrypted connection, authenticate via the build in SMP, and then exchange confidential information.

  • How do you establish the OTR keys as trusted?
    – user
    Commented May 23, 2014 at 13:27
  • 1
    @Michael: As written above and explained in detail in the linked specifications, OTR supports SMP (Socialist Millionaires' Protocol) for authentication which is man-in-the-middle safe. (Assuming that you and your communication partner know each other well enough to have accidentally created a 'shared secret' i.e. any mutually known but private fact.) See e.g. en.wikipedia.org/wiki/Socialist_millionaire
    – Echsecutor
    Commented May 26, 2014 at 13:32

I would use some kind of secure online portal that your remote users can access/download the sensitive information from. To give them access to the portal, I recommend two-factor authentication with a temporary (secure) password that must be changed upon using it once (but the two-factor auth ensures that even if the email with the temp pass is compromised, there is still an sms pin).


First, I hope that you've got your credentials set up so the user MUST change them during the first login, so those setting them up cannot know them anymore.

If a remote office has a trusted admin, send that admin an encrypted set of one time use keys/passwords to share with other users, so you can just ask them to use Password #12 for their initial login.

Depending on your threat model (are you worried about nation-state level actors, i.e. are you working with a foreign office in Country 4, which may engage in commercial espionage on behalf of their local competitors of yours), this is actually a classic case where calling someone on a landline is a great solution.

Just calling someone on a landline and telling them the initial login credentials over the phone works very well.

Beyond that, GPG is always a classic way of doing this, as many people answered. I have examples of both public key usage as well as more secure than default symmetric usage in this answer on Superuser.com.

Depending on your regulatory requirements, OTR is a method of encrypting communications, particularly IM's (see Pidgin as an example) that also allows for "shared secret" authentication; you could share an easy to type password on the phone while on IM's to validate the IM session doesn't have a Man in the Middle, or use some aspect of the work they're doing that would be hard for someone else to have ahold of.

If you already have a way to send email that you trust only your recipient and your own network/email admins can access, and you can trust certain other products/companies, then you could use a "secure email" service like Cisco Registered Envelope Service or an alternate.

Particularly for SSH keys or extremely long and difficult passwords, you can do a combination of these; you can encrypt - perhaps using GPG symmetric mode (see link above) - using a secure password, and then deliver that password via the phone or other method, so they can decrypt the actual authentication token/SSH key/certificate/etc.


All depends on the threat model and the working scenario.

First, please note that in 2021 most emails, and at least all emails through major business providers are transport-encrypted, and plaintext SMTP is deprecated in any decent business environment. Eavesdropping is not part of the threat model.

Impersonation? I assume, because it's not disclosed in the question, that the user(s) are member of the same organization or another trusted organization. Make sure you send emails to the correct domain, do never just hit reply for credential requests coming from someone who claims to be your collaborator. Double-check the destination address in your email client before sending, type in the email address if necessary.

Credential abuse? If you believe that someone will continue to use the passwords after the job is done, you should have plans to change them before and after work. I understand that production passwords are often related to applications. When possible, set up dedicated accounts with same permission levels. This is also good for auditing

Credentials stolen after mailbox leaks (in the future). A regular password rotation policy is good at mitigating this.

For SSH, as noted by @SimonRichter, the flow is opposite. You have them send you the public key, but yet again you must validate the sender address. Either make sure the (business) domains enforce DKIM/DMARC, or call the party over the phone to a trusted number to verify the signature.

When possible, I'd always recommend to switch to SSO and federated login. If this is supported by the underlying applications (e.g. MS SQL Server, Azure SQL), you won't be giving the password to anybody, but granting access to a directory user (e.g. (Azure) Active Directory)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .