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.

  • 7
    Have you thought about using GPG? – executifs May 22 '14 at 12:15
  • 1
    You can use LastPass to share passwords safely with others – Ranhiru Jude Cooray May 23 '14 at 9:52
  • I encountered this exact problem and decided to build a one-off RSA encryption using Javascript. FAQ explains why it is safe (e.g. your password is never sent to the server) You can try it here: tanin.nanakorn.com/labs/secureMessage – Tanin Dec 26 '14 at 13:48

12 Answers 12


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 May 22 '14 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. – Michael Kropat May 22 '14 at 20:11
  • 1
    SMS is even better when you use something like TextSecure. – Greg Hewgill May 23 '14 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 May 23 '14 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 May 29 '14 at 19:03

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 May 22 '14 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 May 22 '14 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 May 22 '14 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 Chung May 25 '14 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. – Darren Cook May 27 '14 at 8:39

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.

  • 7
    This is an excellent solution if you don't mind someone else getting the password instead. – Lily Chung May 22 '14 at 17:42
  • 7
    @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 May 22 '14 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 Chung May 23 '14 at 4:03
  • 3
    @IstvanChung you can also host an instance of this service yourself since they have published the source. – JE42 May 25 '14 at 8:00
  • 3
    I run OTS in an enterprise environment. It's great. We've reskinned it and locked it down on a minimal VM. – Vasili Syrakis May 26 '14 at 14:27

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. – a CVn May 24 '14 at 19:34
  • @MichaelKjörling you are right, but does not scale well if you have a lot of these folder outstanding – Giulio Vian Jul 9 '15 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 – Kolob Canyon Dec 16 '16 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.

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? – a CVn May 23 '14 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 May 26 '14 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.

protected by Rory Alsop May 23 '14 at 12:11

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.