Come qualcuno che di solito lavora con persone di altri paesi, è sempre stato un problema inviare le informazioni di accesso l'una all'altra.
Per i dettagli di accesso allo sviluppo come i database di debug ecc. posso inviarli tramite e-mail in chiaro o qualcosa del genere, ma quando si tratta di informazioni di produzione reali come le chiavi SSH, come inviarli a qualcuno quando il contatto faccia a faccia non è t possibile.
Di solito uso gli SMS. Anche se non perfettamente sicuro, questo è più sicuro della posta elettronica e generalmente adeguato. Ha il grande vantaggio di non richiedere alcuna configurazione, come lo scambio di chiavi PGP.
Potresti renderlo più sicuro inviando metà della password via email e metà via SMS. In alternativa (come suggerito da Michael Kropat) invia un file con la password simmetricamente crittografata via e-mail e invia la password di decrittografia.
Per le chiavi SSH, devi solo trasferire la chiave pubblica. Se stai concedendo a un utente l'accesso a un server, questi dovrebbe inviarti la loro chiave pubblica, piuttosto che inviare loro una chiave privata. Devi comunque confermare che la chiave ricevuta sia autentica, ma non devi mantenerla riservata.
Come è già stato detto nel commento, questo è un caso d'uso classico per GPG / PGP. Ognuno crea una chiave, le scambia in modo arbitrario e quindi verifica le impronte digitali tramite telefono, una chat video o qualsiasi altro canale con una protezione ragionevole contro la manomissione dei dati.
Puoi anche firmare le chiavi dell'altro per creare una piccola rete di fiducia. Ad esempio, se hai già verificato e firmato le chiavi dello sviluppatore A e dello sviluppatore B, allora A e B possono fidarsi l'un l'altro senza dover verificare nuovamente le chiavi.
Quando ho bisogno di inviare qualcosa una sola volta, ho usato One Time Secret . È un'app Web open source che consente di inserire informazioni che possono essere visualizzate solo una volta. Dopo che il destinatario ha aperto la pagina, le informazioni vengono eliminate e l'unica cosa che rimane nei registri della chat o nella posta elettronica è un collegamento errato.
Non è robusto come l'intero team che utilizza PGP, ma è molto più facile da configurare o spiegare. Sono stato in grado di usarlo per inviare informazioni di accesso a persone non tecniche e lo trovano facile da usare.
Per le chiavi SSH, ho loro generare la chiave e inviarmi la chiave pubblica, quindi possiamo semplicemente confrontare le impronte digitali al telefono.
È possibile utilizzare il metodo lento per spedirli (postali) sui tasti su una chiave USB, ma che nell'età di oggi non è pratico. Quello che faccio in situazioni come questa è che ho un server web dedicato alle operazioni NOC che uso per memorizzare le chiavi in una directory che creerò per chi devo mandare le chiavi. Blocca il server web con le regole mod_security e .htaccess per consentire SOLO all'individuo di vedere quella directory (tramite IP).
La mia struttura è qualcosa di simile al seguente. Supponiamo di dover creare una chiave per dire un gruppo di sviluppatori in Cina, creerò una directory basata sul checksum del loro nome / gruppo, ecc.
[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 .
Questo garantisce che nessuno possa imbattersi in una directory usando qualcosa come Nikto / Wikto, ecc. Le regole .htaccess e mod_security mi permettono di controllare chi arriva a quella directory, e posso ripulirlo dopo aver visto i log, il le chiavi sono state copiate.
Probabilmente non hai bisogno di mandare le chiavi segrete ssh in giro.
L'individuo remoto dovrebbe generare una coppia di chiavi all'estremità, mantenere la chiave segreta e inviarti la chiave pubblica.
La chiave pubblica non è un segreto, quindi non è un problema mandarlo in chiaro. Solo la chiave privata è segreta e non è necessario che sia trasmessa perché è già presente.
Quindi aggiungi la loro chiave pubblica all'elenco delle chiavi autorizzato.
L'unico problema che potresti avere è determinare che la chiave pubblica che hai ricevuto sia realmente dalla persona a cui vuoi dare accesso.
Se hai altre informazioni segrete che devi condividere, beh, ora hai entrambi accesso sicuro al server condiviso per poterlo usare.
Se ognuno di essi può configurare un account con un sito di condivisione file sicuro, è possibile condividere file con ciascuno di essi. Se vuoi farlo da solo, puoi configurare qualcosa come OwnCloud con la crittografia abilitata e usarla come mezzo per lo scambio sicuro di file con più persone, purché tu usi SSL per l'istanza di OwnCloud e possa fare una distribuzione sicura delle credenziali fuori banda .
Il problema principale è che stiamo inviando le password normalmente a utenti semplici, che hanno problemi ad aprire una mail con firma gpg.
Qual è il problema reale peggiorato dal fatto che il nostro lavoro / salario / progetto dipende dal loro giudizio, quanto sono contenti di collaborare con noi. Inoltre, la nostra prima priorità è rendere questa password-cosa il più semplice possibile per loro. Mi dispiace dirlo, ma nella realtà è più importante ridurre la possibilità di una rottura dallo 0,1% allo 0,01% nel prossimo mese.
Normalmente faccio quanto segue:
Con PGP / GPG (e la maggior parte delle altre risposte suggerite) devi risolvere il problema di autenticazione per prevenire gli attacchi man in the middle. Gli SMS non dovrebbero essere considerati salvati, poiché la crittografia GSM è stata a lungo compromessa.
Vorrei usare OTR (non posso pubblicare più link, solo google).
Con alcuni client di chat, come pidgin . È quindi possibile utilizzare anche un canale non sicuro, come Facebook, chat di Google, ICQ, qualsiasi cosa, stabilire una connessione crittografata, autenticarsi tramite build in SMP , quindi scambia informazioni riservate.
Utilizzerei un qualche tipo di portale online sicuro a cui gli utenti remoti possono accedere / scaricare le informazioni sensibili. Per consentire loro l'accesso al portale, raccomando l'autenticazione a due fattori con una password temporanea (sicura) che deve essere modificata dopo averla utilizzata una volta (ma l'autenticazione a due fattori garantisce che anche se l'e-mail con il pass temporaneo è compromessa, lì è ancora un pin sms).
Per prima cosa, spero che tu abbia le tue credenziali impostate in modo che l'utente DEVE cambiarle durante il primo accesso, quindi quelle che le hanno configurate non possono più conoscerle.
Se un ufficio remoto ha un amministratore fidato, invia a quell'amministratore un set crittografato di chiavi / password monouso da condividere con altri utenti, quindi puoi semplicemente chiedere loro di usare la password n. 12 per il loro accesso iniziale.
A seconda del tuo modello di minaccia (sei preoccupato per gli attori a livello nazionale, cioè stai lavorando con un ufficio estero nel Paese 4, che può impegnarsi in spionaggio commerciale per conto dei tuoi concorrenti locali), questo è in realtà un classico caso in cui chiamare qualcuno su una rete fissa è un'ottima soluzione.
Basta chiamare qualcuno su una rete fissa e dirgli che le credenziali di accesso iniziali al telefono funzionano molto bene.
Oltre a ciò, GPG è sempre un modo classico per farlo, come hanno risposto molte persone. Ho esempi di utilizzo della chiave pubblica e più sicuro dell'uso simmetrico predefinito in questa risposta su Superuser.com .
A seconda dei requisiti normativi, OTR è un metodo di crittografia delle comunicazioni, in particolare di IM (vedi Pidgin come esempio) che consente anche l'autenticazione "shared secret"; è possibile condividere una password facile da digitare sul telefono mentre su IM per convalidare la sessione di messaggistica istantanea non ha un uomo in mezzo, o utilizzare alcuni aspetti del lavoro che stanno facendo che sarebbe difficile per qualcun altro avere di.
Se hai già un modo per inviare email di cui ti fidi solo al tuo destinatario e che la tua rete / gli amministratori di posta elettronica possono accedere, e puoi fidarti di certi altri prodotti / società, allora potresti usare un servizio di "email sicura" come < a href="https://res.cisco.com/websafe/about"> Cisco Envelope Service registrato o un altro.
In particolare per le chiavi SSH o le password estremamente lunghe e difficili, puoi fare una combinazione di queste; puoi crittografare - magari usando la modalità simmetrica GPG (vedi link sopra) - usando una password sicura, e poi consegnare quella password tramite il telefono o altro metodo, in modo che possano decifrare il token di autenticazione effettivo / chiave SSH / certificato / ecc.
Leggi altre domande sui tag authentication