J'utilise habituellement les SMS. Bien qu'il ne soit pas parfaitement sécurisé, il est plus sûr que le courrier électronique et généralement adéquat. Il a l'avantage majeur de ne nécessiter aucune configuration, comme l'échange de clés PGP.

Vous pouvez rendre cela plus sécurisé en envoyant la moitié du mot de passe par e-mail et l'autre moitié par SMS. Alternativement (comme suggéré par Michael Kropat) envoyez un fichier avec le mot de passe crypté symétriquement par e-mail, et envoyez le mot de passe de décryptage par SMS.

Pour les clés SSH, vous ne devez transférer que la clé publique. Si vous accordez à un utilisateur l'accès à un serveur, il doit vous envoyer sa clé publique, plutôt que vous lui envoyez une clé privée. Vous devez toujours confirmer que la clé reçue est authentique, mais vous n'avez pas besoin de la garder confidentielle.

Lorsque j'ai besoin d'envoyer quelque chose une seule fois, j'ai utilisé One Time Secret. C'est une application Web open source qui vous permet de saisir des informations qui ne peuvent être consultées qu'une seule fois. Une fois que le destinataire a ouvert la page, les informations sont supprimées et la seule chose qui reste dans vos journaux de discussion ou vos e-mails est un mauvais lien.

Ce n'est pas aussi robuste que toute votre équipe utilisant PGP, mais c'est beaucoup plus facile à configurer ou à expliquer. J'ai pu l'utiliser pour envoyer des informations de connexion à des personnes peu techniques, et elles le trouvent facile à utiliser.

Comme cela a déjà été dit dans le commentaire, il s'agit d'un cas d'utilisation classique pour GPG / PGP. Tout le monde crée une clé, vous les échangez de manière arbitraire, puis vous vérifiez les empreintes digitales au téléphone, dans un chat vidéo ou tout autre canal avec une protection raisonnable contre la falsification des données.

Vous pouvez également vous signer les uns les autres «clés pour créer un petit réseau de confiance. Par exemple, si vous avez déjà vérifié et signé les clés du développeur A et du développeur B, alors A et B peuvent se faire confiance sans avoir à vérifier à nouveau les clés.

Pour les clés SSH, je leur demande de générer la clé et de m'envoyer la clé publique, puis nous pouvons simplement comparer les empreintes digitales au téléphone.

Vous pouvez utiliser la méthode lente pour leur envoyer (par courrier) les clés sur une clé USB, mais cela n'est pas pratique à notre époque. Ce que je fais dans des situations comme celle-ci, c'est que j'ai un serveur Web dédié aux opérations NOC que j'utilise pour stocker les clés dans un répertoire que je créerai pour qui je dois envoyer des clés. Je verrouille le serveur Web avec les règles mod_security et .htaccess pour permettre UNIQUEMENT à l'individu que je souhaite voir ce répertoire (via IP).

Ma structure est similaire à la suivante. Supposons que je doive créer une clé pour, par exemple, un groupe de développement en Chine, je créerai un répertoire basé sur la somme de contrôle de leur nom / groupe, etc:

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

Cela garantit que personne ne peut tomber sur un répertoire en utilisant quelque chose comme Nikto / Wikto, etc. les règles .htaccess et mod_security me permettent de contrôler qui accède à ce répertoire, et je peux le nettoyer après avoir vu via les journaux, les clés ont été copiées.

Vous n'avez probablement pas besoin d'envoyer des clés secrètes ssh.

L'individu distant doit générer une paire de clés de son côté, conserver la clé secrète et vous envoyer la clé publique.

La clé publique n'est pas un secret, donc ce n'est pas un problème de l'envoyer en clair. Seule la clé privée est secrète, et cela n'a pas besoin d'être transmise car ils l'ont déjà.

Ensuite, vous ajoutez simplement leur clé publique à la liste des clés autorisées.

Le le seul problème que vous pourriez avoir est de déterminer que la clé publique que vous avez reçue provient vraiment de la personne à laquelle vous souhaitez donner accès.

Si vous avez d'autres informations secrètes que vous devez partager, eh bien, maintenant vous deux avoir un accès sécurisé au serveur partagé afin que vous puissiez l'utiliser.

Si vous avez tous deux créé un compte avec LastPass, ce service vous permet de partager vos mots de passe (et d'autres informations sécurisées) avec d'autres parties.

S'ils peuvent chacun configurer un compte avec un site de partage de fichiers sécurisé, vous pouvez partager des fichiers avec chacun d'eux. Si vous souhaitez le faire vous-même, vous pouvez configurer quelque chose comme OwnCloud avec le cryptage activé et l'utiliser comme moyen d'échange de fichiers sécurisé avec plusieurs personnes tant que vous utilisez SSL pour l'instance OwnCloud et que vous pouvez effectuer une distribution d'informations d'identification sécurisée hors bande. .

Le principal problème à ce sujet est que nous envoyons des mots de passe normalement à des utilisateurs simples, qui ont des problèmes pour ouvrir un courrier signé par gpg.

Quel est le problème réel aggravé par cela notre travail / salaire / projet dépend de leur jugement, à quel point ils sont heureux de collaborer avec nous. Notre première priorité est également de rendre ce mot de passe aussi simple que possible pour eux. Je suis désolé de le dire, mais dans la réalité, il est plus important de réduire le risque de rupture de 0,1% à 0,01% le mois prochain.

Normalement, je fais ce qui suit:

• J'envoie tout (nom d'utilisateur, informations de connexion supplémentaires) dans un courrier simple et non chiffré, sauf le mot de passe réel,
• Je renvoie le mot de passe réel comme " Je vous l'ai envoyé par SMS "
• Et j'envoie un SMS en même temps que le mail, uniquement avec le mot de passe simple, sans aucun commentaire.

Avec PGP / GPG (et la plupart des autres réponses suggérées), vous devez résoudre le problème d'authentification pour empêcher les attaques man in the middle. Les SMS ne doivent pas être considérés comme sauvegardés, car le cryptage GSM a longtemps été piraté.

J'utiliserais OTR (je ne peux pas publier plus de liens, juste Google).

Avec un client de chat, tel que pidgin. Vous pouvez même utiliser un canal non sécurisé, tel que Facebook, Google chat, ICQ, quoi que ce soit, établir une connexion cryptée, vous authentifier via le build in SMP, puis échanger des informations confidentielles.

J'utiliserais une sorte de portail en ligne sécurisé auquel vos utilisateurs distants peuvent accéder / télécharger les informations sensibles. Pour leur donner accès au portail, je recommande l'authentification à deux facteurs avec un mot de passe temporaire (sécurisé) qui doit être changé lors de son utilisation une fois (mais l'authentification à deux facteurs garantit que même si l'e-mail avec le pass temporaire est compromis, il est toujours une épingle SMS).

Tout d'abord, j'espère que vous avez configuré vos informations d'identification afin que l'utilisateur DOIT les modifier lors de la première connexion, afin que ceux qui les configurent ne puissent plus les connaître.

Si un bureau distant a un Administrateur de confiance, envoyez à cet administrateur un ensemble chiffré de clés / mots de passe à usage unique à partager avec d'autres utilisateurs, afin que vous puissiez simplement leur demander d'utiliser le mot de passe n ° 12 pour leur connexion initiale.

En fonction de votre modèle de menace (êtes-vous préoccupé par les acteurs au niveau de l'État-nation, c'est-à-dire travaillez-vous avec un bureau étranger dans le pays 4, qui peut se livrer à l'espionnage commercial au nom de vos concurrents locaux), il s'agit en fait d'un cas classique où appeler quelqu'un sur un la ligne fixe est une excellente solution.

Le simple fait d'appeler quelqu'un sur une ligne fixe et de lui indiquer les informations de connexion initiales par téléphone fonctionne très bien.

Au-delà de cela, GPG est toujours un moyen classique de faire cela, comme de nombreuses personnes ont répondu. J'ai des exemples d'utilisation de clé publique et d'utilisation symétrique plus sécurisée que par défaut dans cette réponse sur Superuser.com.

En fonction de vos exigences réglementaires, OTR est une méthode de cryptage des communications, en particulier des messages instantanés (voir Pidgin à titre d'exemple) qui permet également une authentification par "secret partagé"; vous pouvez partager un mot de passe facile à taper sur le téléphone lorsque vous êtes sur la messagerie instantanée pour valider que la session de messagerie instantanée n'a pas d'homme au milieu, ou utiliser un aspect du travail qu'ils font qui serait difficile pour quelqu'un d'autre de.

Si vous disposez déjà d'un moyen d'envoyer des e-mails auxquels vous ne faites confiance que votre destinataire et que les administrateurs de votre propre réseau / e-mail peuvent accéder, et que vous pouvez faire confiance à certains autres produits / sociétés, vous pouvez utiliser un " service de messagerie sécurisé "comme le service d'enveloppes enregistrées Cisco ou un autre service.

En particulier pour les clés SSH ou les mots de passe extrêmement longs et difficiles, vous pouvez faire une combinaison de ceux-ci; vous pouvez chiffrer - peut-être en utilisant le mode symétrique GPG (voir le lien ci-dessus) - en utilisant un mot de passe sécurisé, puis fournir ce mot de passe via le téléphone ou une autre méthode, afin qu'ils puissent déchiffrer le jeton d'authentification réel / clé SSH / certificat / etc.