Domanda:
È completamente sicuro pubblicare una chiave pubblica ssh?
Brian
2017-02-07 00:53:56 UTC
view on stackexchange narkive permalink

Uso una chiave RSA per accedere a server remoti con ssh. E tengo i miei file punto sotto il controllo della versione in un luogo accessibile pubblicamente in modo da poter configurare rapidamente nuovi server in modo che funzionino come mi piace.

In questo momento non ho la mia directory .ssh sotto il controllo della versione. Ma salverebbe un passaggio se potessi mantenere .ssh / authorized_keys nel repository dotfile.

È solo una chiave pubblica. La mia chiave privata si trova solo su macchine client affidabili in mio possesso, ovviamente. L'ho creata una chiave RSA a 4096 bit perché sembra il miglior equilibrio tra un'ampia compatibilità con le versioni sshd comuni e la sicurezza.

Quindi la mia domanda è: c'è qualche problema di sicurezza con la pubblicazione letteralmente pubblica della chiave pubblica ? Nessuno annusa regolarmente il mio repository dotfiles, ma non è un segreto e chiunque sia interessato potrebbe leggerli.

La chiave pubblica deve essere pubblica, quindi sì.Dovrebbe essere a posto.Se non è necessario che tu lo faccia, non pubblicarlo senza motivo, ma dovresti stare bene.
Ehi, mettere .ssh sotto il controllo della versione è un'idea chiara.Mi chiedo perché non ci ho mai pensato.
Definisci "completamente sicuro".Posso picchiarti con un tubo di gomma finché non mi hai detto la risposta?Posso spendere trilioni di dollari e milioni di anni per tentare di romperlo?
Nick: Amico, se vuoi così tanto le schede del vocabolario dei miei utenti, rompi la finestra del mio ufficio e clona il mio disco rigido.Tanta aggressività.
Penso che non valga nulla che GitHub pubblichi le chiavi pubbliche di tutti i suoi utenti.[Non devi nemmeno essere loggato.] (Https://github.com/coding-horror.keys)
Solo un'osservazione: niente in IT è completamente sicuro, a parte gettare il sistema in un trituratore industriale e poi gettare i frammenti in un altoforno.
@NZKshatriya e lanciare l'altoforno al sole, e poi lanciare il sole in un buco nero ...
@djsmiley2k Quel buco nero NON è perfettamente sicuro.Stephen Hawking ha ribaltato la sua opinione originale.Non è lecito ritenere che nessuna informazione fuoriesca da un buco nero ;-).Un simile serbatoio di informazioni contraddirebbe i principi fondamentali di come funziona l'universo.Ad esempio, potrebbe essere utilizzato per eliminare il disordine sui miei dischi rigidi.Ahimè ...
Tieni presente che se non sei disposto a pubblicare la tua chiave pubblica, la tua chiave privata non sarà di alcuna utilità.
Un'altra osservazione da parte di un non esperto: è ragionevolmente sicuro condividere la chiave pubblica, ma è sicuro prendere le authorized_keys da un repository condiviso?Se ti fidi completamente del repository di controllo delle versioni ok, ma se qualcun altro può accedere al repository e modificarlo, sarà in grado di ottenere l'accesso a tutti i PC che utilizzano quel file ... Se per te va bene condividilo ...
@Brian: XKCD obbligatorio che si adatta all'idea di Nick T: https://xkcd.com/538/
Secondo @frarugi87: è sicuro pubblicare la tua chiave pubblica, ma se va bene scaricare automaticamente e fidarsi di una chiave pubblica da qualche parte dipende molto da quanto sia sicuro quel luogo.
Nick potrebbe essere diventato un po 'aggressivo con la formulazione, ma il suo punto è buono.Il termine "completamente sicuro" è un anatema per gli addetti alla sicurezza perché non esiste qualcosa come "completamente sicuro".Se rimuovi la parola "completamente" e chiedi semplicemente "è sicuro", eviti questo tipo di problemi.(ovviamente, apportare questa modifica ora invaliderebbe la maggior parte delle risposte)
@Brian "tubo di gomma" è per https://en.wikipedia.org/wiki/Rubber-hose_cryptanalysis;Non intendevo aggressione, anche se forse il termine non è così noto al di fuori degli esperti di sicurezza.
@CortAmmon: "È sicuro?"è probabilmente ** peggiore ** di "È completamente sicuro?"perché hai sostituito una domanda a cui rispondere con una vaga imprecisa!È meglio chiedere "È sicuro come ...?"
@Brian Non è una questione di aggressività, è una questione di un difetto fondamentale nella tua domanda."Completamente sicuro" è un'espressione priva di significato in queste discussioni perché se uno schema dovrebbe garantire l'accesso ad alcune persone mentre ne tiene fuori altre, allora non puoi mai escludere la fortuna cieca.Quindi è probabile che qualcuno non riesca a capire la tua chiave privata 100.0000000000000% se pubblichi la tua chiave pubblica?No non lo è.Ma non è mai l'obiettivo di creare qualcosa di "Completamente Sicuro", perché è impossibile.L'obiettivo è renderlo "abbastanza sicuro".
Direi che * non * è sicuro mettere le tue `authorized_keys` in un repository pubblico.Se l'operatore di questo repository (ad esempio, GitHub) è compromesso, sarà in grado di sostituire / aggiungere la propria chiave pubblica e successivamente accedere a tutti i server in cui cloni questo file!
Undici risposte:
#1
+104
CaffeineAddiction
2017-02-07 00:58:17 UTC
view on stackexchange narkive permalink

Le chiavi pubbliche sono progettate per la condivisione, l'accesso in lettura e / o la pubblicazione di una chiave pubblica va bene

Le chiavi private sono segrete, dovrebbero solo essere accessibile al proprietario di detta chiave privata.

Per riportare questo punto a casa, ripensa a ogni sito web HTTPS che hai mai visitato. In ogni caso, come parte di HTTPS, il sito ti fornisce la loro chiave pubblica. Quindi non solo è sicuro pubblicarlo, ma dovrebbe essere in questo modo. Ad esempio, se fai clic sull'icona del lucchetto verde sulla barra degli indirizzi, puoi trovare la chiave pubblica per questo sito Web (se la stai visualizzando su HTTPS)

  * .stackexchange.comModulus ( 2048 bit): af 46 03 ce c7 13 e6 2e 93 d8 56 91 b1 31 8d 0a 22 c1 f0 eb 4f 5e ef 0d f6 20 32 b9 a4 4e 87 f9 d2 d2 44 51 b0 df 30 50 c9 35 4e 68 19 84 fb 98 33 aa 05 4b 7e fb 57 c5 b6 2e a8 4b 04 ca cf 5e 2e e5 9e 1b ca b7 60 c5 58 2c b0 df c4 6b 0d b1 2c 33 97 73 54 61 2b 9a 1b b1 dc 5d 10 a9 c4 c8 f7 6c e3 55 6e b5 0e 61 3b 35 24 0b 89 1e 32 a2 75 69 4e 97 40 68 ee 23 48 f2 71 9f c7 7e e2 9d 6c 22 55 36 24 64 a4 f0 b6 52 58 5a 9a 44 e7 3b 2a d5 ed 95 63 f8 1d a8 4d 45 9b 5d c2 f2 f9 74 81 06 18 d5 b1 fb b0 7e 5d 50 1f 63 5c a0 73 f5 22 b2 57 64 03 e6 b7 0f 6f b7 58 0b 57 80 56 51 65 9f f5 09 61 63 29 62 4d 30 02 3a 64 10 2d 95 b8 12 36 04 58 c5 d7 1d 95 e2 21 3c b0 b3 93 35 b2 b1 f9 6d 7e 20 66 b2 68 33 e9 50 a8 15 1e 0a 80 9a 3c 19 dd cc 79 35 a8 8c 1b 61 33 5d 12 2f Esponente (24 bit): 65537  

Ulteriori esempi di questo possono essere trovati su github.com dove richiedono di allegare una chiave pubblica al tuo account da utilizzare con git clone [email protected]: <user> / <repo>

Puoi effettivamente controllare le chiavi pubbliche di qualsiasi utente su GitHub con il seguente URL

https://api.github.com/users/<user>/keys

il mio è elencato come:

  [{"id": 18667533,
"Chiave": "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDraswAp7EbMwyYTzOwnSrsmr3nNMDaDf4e2YVaehLc9w6KN2ommomXZO8 / V9N3yINNveGqrcVc9m2NTm04iILJUKd9o25ns8QIG6XSCt9SVx / Xw1J / SXfIWUKuEe0SgmIwVwkk8jetfG / Z7giSiU3dxxC4V9lHQCFgKOKBWGpNbINmqtmBWncX3HJKeXrpSddoePbZZ84IEFr4CWUlqoXyphpxqzpfA9sRpVTtyBPcUSj68j4 + gKgEQN65G6LXys3q8BiwWxucci6s34vp4L8jKn7uYh26vLuT1oIbODJphCmpvMH + ABPkNQcFBk4rRLpCEAsoAhmvTk / NjnfZM + nd"}, { "id": 21.175.800, "chiave": "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC5tPV481acCZ5wm2E15gXkVRaKCE3lic / O8licyzW + eDE9rPpG4rHRRH9K2ENmstUh5nLEenb0nNhEGnsf3pIJRZ07JXwv16 + lsJBSS8 + YiWeMBlwo + JNaxwSyUlYUgl1ruogr0nR0KBqsYSWXuG0s2jm2IOV + 0B / 0fzDR / tiLFLj50 + iJ9qCDSk / 8fAsXz2xG39KcUcxmCbDXb / qSdESWaZc + pafNRiCcVNfMkKeDViWlzI4VkiTcfVCraHUuYx4jgOBB526dRWSDG9bLchwlJiopgT + k4X / TNe2l01DPwYetwLvY6V8rcPrjjJL8ifRTMSof1zRIoBgJZhRzWc1D"}]  

L'esatto contrario è vero per chiavi private che dovrebbe essere sempre protetto e mai ceduto a terzi o scambiato via e-mail senza crittografia ing.

Se qualcuno ha avuto accesso alla tua chiave privata, ha la possibilità di accedere a qualsiasi dispositivo o file crittografato che era protetto con la tua chiave pubblica. Significa anche che possono firmare cose per tuo conto. È MOLTO dannoso se qualcuno ha ottenuto l'accesso alla tua chiave privata.

In molti casi i client SSH non funzioneranno se viene rilevato che i permessi del file della chiave privata sono tali che gli utenti diversi da te abbiano accesso in lettura.

Immagino che questo potrebbe essere migliorato esponendo il motivo per cui le chiavi private sono private e così via
Semplicisticamente, due numeri primi scelti a caso sono la chiave privata e moltiplicati insieme formano la chiave pubblica.Questo è fattibile perché i numeri primi sono abbastanza comuni.RSA si basa sull'ipotesi (tecnicamente non dimostrata) che riportarli ai due numeri primi sia difficile.
@J.A.K: Per espandere questo punto, la chiave privata non è in realtà il prodotto dei due numeri primi pe q.È l'inverso modulare dell'esponente della chiave pubblica e sul modulo p * q.Il modulo p * q ed e sono pubblicati.Se puoi fattorizzare p * q, conosci peq e puoi calcolare l'inverso modulare di e.
Non credo che la maggior parte delle persone faccia clic su questa pagina per comprendere le sfumature matematiche sottostanti, perché la domanda riguarda le proprietà di base di cosa sia una chiave pubblica."La sicurezza sta in ...." sarebbe stata una frase migliore, sono d'accordo.Ma credo che questo sia anche il motivo per cui è stato generato RSA-129;per mostrare la durezza della fattorizzazione in modo comprensibile
D'accordo, ma il mio commento spiega cosa sono il modulo e l'esponente nell'esempio di scambio di stack sopra.Inoltre il fatto che il modulo * non * sia l'intera chiave rende possibile riutilizzare il modulo in software come ssh e scegliere solo esponenti diversi, ed è per questo che è probabile che le agenzie di tre lettere siano interessate a spendere miliardi di dollari per fattorizzaresolo pochi numeri - se possono fattorizzare un modulo usato spesso, ogni chiave pubblica che è effettivamente disponibile in pubblico e basata su quel modulo è una porta istantanea alla chiave privata.Quindi penso che sia rilevante per la domanda.
@Pascal umm Penso che tu stia confondendo RSA con DH.Con RSA il modulo deve essere distinto per ogni coppia di chiavi.Se hai il modulo ed entrambi gli esponenti, puoi recuperare peq http://www.di-mgt.com.au/rsa_factorize_n.html.
Bene, sì, il punto sul riutilizzo in effetti si applica al DH (vedi la mia risposta sul riutilizzo delle costanti nel DH - non dovrei sorvolare sui dettagli quando punto il dito ... scusa!).Il problema immediato con * tutte * le chiavi ssh che condividono lo stesso modulo RSA sarebbe che per calcolare la coppia di chiavi quando si genera una nuova coppia di chiavi, è necessario accedere a peq, i fattori del modulo n.Quindi, se ssh riusasse lo stesso modulo per ogni chiave RSA, il suo codice sorgente conterrebbe peq come costanti.Quindi potremmo semplicemente cercare peq nel codice sorgente - non c'è bisogno di calcolare (o spendere) nulla :-)
È interessante notare che, quando stavo visualizzando la tua risposta su HTTP (senza S), la risposta diceva ** "Certo, puoi pubblicare le tue chiavi pubbliche _e_ private, nessun problema" **.
@Pascal: Il tuo primo commento sulla chiave privata è ** totalmente sbagliato **.L'inverso modulare di qualsiasi numero intero su qualsiasi modulo è ** facilmente calcolabile ** (in tempo logaritmico).La chiave privata è l'inverso moltiplicativo della chiave pubblica modulo (p-1) * (q-1), non p * q.p * q è pubblicato, ma (p-1) * (q-1) è difficile da calcolare senza conoscere p o q.
@J.A.K .: Vedi il mio commento sopra.E se qualcuno è realmente interessato alla sicurezza, sta a lui capire abbastanza matematica per non fare cose stupide.Molti professionisti della sicurezza che non finiscono per rendere i propri sistemi insicuri per ragioni molto ingenue da un punto di vista matematico.
@user21820: Sì, hai ragione.Come ho detto, non dovrei puntare il dito e sbagliare anche tu!La prossima volta lo cercherò invece di cercare di spiegarlo a memoria prima di diventare un idiota ;-) E scusa, J.A.K.
@Pascal: Nessun idiota ammetterà gli errori.Inoltre, mi ha divertito il fatto che la tua risposta effettiva non affermasse nulla di sbagliato su RSA, a differenza di qui.=)
Suggerimento rapido sulle chiavi GitHub.Se utilizzi l'URL https://github.com/user.keys, verranno restituiti pronti per essere inseriti nelle chiavi autorizzate.
@Pascal Non hai idea di quanto spesso lo incasino io stesso;).Il fatto che le persone si mettano in gioco lo rende un posto fantastico, il resto si risolverà da solo.
#2
+59
Out of Band
2017-02-07 01:35:27 UTC
view on stackexchange narkive permalink

È completamente sicuro pubblicare una chiave pubblica ssh?

No, ma puoi farlo comunque senza preoccupazioni (molte persone lo fanno, basta guardare https://sks-keyservers.net/i/ o https://pgp.mit.edu/)

Il motivo per cui non è completamente sicuro è perché se conosco la tua chiave pubblica, posso, con un bel pezzo di matematica, calcolare la tua chiave privata. La tua chiave pubblica contiene un numero elevato n che è fondamentalmente il prodotto di due numeri primi e, se trovo questi due numeri primi, posso trovare facilmente la tua chiave privata.

Il motivo per cui non hai preoccuparsi: è facile trovare i fattori di n quando n = 21, ma è molto più difficile quando n è un numero lungo 4096 bit. Nessun matematico attualmente vivo o morto ha pubblicato un modo per fattorizzare un numero così elevato in tempi accettabili. Usando il metodo più conosciuto, saremmo tutti morti molto, molto prima che qualcuno scoprisse i fattori che compongono il tuo n .

Non è del tutto impossibile che qualcuno trovi una scorciatoia per fattorizzare grandi numeri. Se ciò accade, RSA sarà inutile. Fino ad allora, non devi preoccuparti.

SSH utilizza sia RSA (o un altro schema di firma) che Diffie Hellman (per lo scambio di chiavi di sessione). 1024 bit per lo scambio di chiavi Diffie Hellmann (che matematicamente funziona in modo leggermente diverso da RSA) potrebbe non essere più abbastanza grande. Questo perché alcune implementazioni ssh (e implementazioni ssl, se ricordo bene) che usano Diffie Hellman riutilizzano alcune costanti invece di sceglierle in modo casuale e una volta che qualcuno ha costruito una macchina per eseguire i calcoli necessari, potrebbero rompere tutta la crittografia basata su queste costanti. 1024 bit richiedono ancora una quantità incredibile di potenza di calcolo per fattorizzare o calcolare logaritmi discreti (e miliardi di dollari per costruire macchine per farlo rapidamente), ma potrebbe valerne la pena per alcuni attori a livello statale, perché basta rompere qualche problema istanze interromperanno un numero così elevato di sessioni crittografate. Tuttavia, 2048 e 4096 bit sono ancora considerati sicuri.

Lo stesso vale per le chiavi RSA; Non penso che un numero di 1024 bit sia stato ancora preso in considerazione in pubblico, ma probabilmente è lì all'orizzonte, il che significa che è probabilmente possibile per istituzioni con budget molto grandi calcolare i numeri di 1024 bit ora , anche se non in grandi quantità.

(Modifiche: chiarito il significato dell'ultimo paragrafo e corretto l'errore segnalato da RobIII)

1024 bit RSA probabilmente sarebbe un po 'troppo vicino per comodità.2048 bit dovrebbe andare bene, 4096 bit aggiunge un discreto margine di sicurezza (ma non tanto quanto, ad esempio, passando da AES-128 a AES-256) * contro gli attacchi attualmente noti al pubblico *.
Concordato.Vedo che l'ultimo paragrafo è fuorviante;Intendevo dire che le chiavi a 2048 e 4096 bit sono sicure anche per RSA mentre le chiavi a 1024 bit probabilmente non lo sono più, dato che anche uno sforzo pubblico / di ricerca potrebbe presto fattorizzarne uno (quindi probabilmente tre agenzie di lettere sono in vantaggio)
"" Nota che ssh ti permette di scegliere tra RSA e Diffie Hellman. "" Potrei sbagliarmi ma le opzioni "RSA1", "DSA", "RSA" (per RSA2), "ECDSA" e "ED25519" non sono?Correggimi se sbaglio.
Hmmm, hai ragione.Mi sono ricordato male: secondo http://security.stackexchange.com/questions/76894/how-does-ssh-use-both-rsa-and-diffie-hellman, sembra che ssh utilizzi RSA per le sue capacità di firma e Diffie Hellmanper lo scambio di chiavi, quindi presumo che Diffie Hellman sia sempre utilizzato come algoritmo di scambio di chiavi indipendentemente dallo schema di firma (RSA1, DSA, ECDSA, ED25519) che utilizzi.Modificherò la risposta per rispecchiarla.
"Nessun matematico attualmente vivo o morto ha pubblicato un modo per fattorizzare un numero così elevato in tempi accettabili".Penso che l'utente @PeterShor potrebbe non essere d'accordo con te
@SteveCox vero, ma recuperabile con l'aggiunta di una parola."utilizzabile".L'hardware in grado di eseguire l'algoritmo di Shor in tempo subesponenziale non esiste ancora.È ancora un bel po 'di tempo lontano, afaik.
@RobIII, Pascal: "RSA1" non è uno schema di firma, significa "RSA per SSHv1", dove la chiave RSA è stata utilizzata per _decryption_ - nel protocollo SSHv1 ormai obsoleto il server crittografava una sfida alla tua chiave.(Ecco perché _solo_ supportava RSA, presumo.) Tutte le altre opzioni sono chiavi di firma per il protocollo SSHv2, e sì, SSHv2 supporta alcuni schemi di firma e usa * DH per lo scambio di chiavi.
@grawity -Ah, non finisci mai di imparare.Questo è il motivo per cui amo stackexchange.Grazie!
#3
+33
Luis Casillas
2017-02-07 07:56:12 UTC
view on stackexchange narkive permalink

Niente è "completamente sicuro"; la domanda è se aggiunge qualche rischio aggiuntivo .

Il protocollo SSH invia la chiave pubblica del client crittografata , solo dopo che ha negoziato una chiave di crittografia di sessione simmetrica con il server. Quindi un avversario che ascolta di nascosto la connessione non apprende la chiave pubblica del client. Ciò significa che pubblicarlo fornisce all'avversario un'informazione in più che altrimenti non avrebbe.

Ma cosa può fare l'avversario con quelle informazioni aggiuntive? Bene, tutto questo dipende dal fatto che l'attaccante possa infrangere la RSA. Consideriamo due sottocasi. (Presumo che sia il server che le chiavi RSA del client siano abbastanza grandi da essere sicure in primo luogo: 2048 bit o più.)

L'avversario ha un attacco generale su RSA che richiede la conoscenza di la chiave pubblica

Per attacco generale, intendo uno che rompe RSA indipendentemente dalla chiave che usi. Ad esempio, questo sarebbe qualcosa come un algoritmo efficiente per risolvere il problema RSA (ad esempio, un algoritmo di fattorizzazione in tempo polinomiale) o costruendo un pratico computer quantistico.

In questo caso non importa se pubblichi o meno la chiave pubblica del client, perché SSH e ogni altra applicazione che utilizza RSA verrebbero completamente danneggiati. Quindi nessun rischio aggiuntivo.

L'attaccante ha un attacco contro un sottoinsieme di chiavi pubbliche RSA "deboli"

Questo è un problema nella vita reale. Ci sono alcuni sistemi che, a causa di algoritmi di generazione di chiavi difettosi o generatori di numeri casuali difettosi, scelgono chiavi RSA che sono effettivamente vulnerabili agli attacchi. L'esempio più notevole è che la distribuzione Debian GNU / Linux è stata fornita con un generatore di numeri casuali debole per quasi due anni (da settembre 2006 a 13 maggio 2008). Un sondaggio del 2011 su 7,1 milioni di chiavi RSA nella rete Internet pubblica ha rilevato che circa lo 0,4% delle 1024 chiavi pubbliche RSA che hanno visto erano deboli.

Se la chiave pubblica del client è una chiave così debole e la pubblichi, un utente malintenzionato che la ottiene potrebbe essere in grado di dirlo e sfruttare questo fatto. Potrebbero quindi accedere ai server SSH a cui usi quella chiave per autenticarti. Sarebbe davvero un rischio aggiuntivo.

Se il tuo server ha una chiave pubblica così debole, allora quel server non è sicuro; un utente malintenzionato può intercettare le connessioni, il che consente loro di apprendere comunque la tua chiave pubblica. Quindi in questo caso non ci sono rischi aggiuntivi.

Conclusione

Il rischio aggiuntivo derivante dalla pubblicazione della chiave pubblica del client SSH è piccolo ma non zero. Il rischio più grande è che la chiave pubblica del client sia debole, qualcosa causato da un software difettoso. Se hai intenzione di pubblicare una chiave pubblica del client, potresti prendere provvedimenti per assicurarti che la tua chiave non sia debole. Ad esempio:

  • Controlla la tua chiave pubblica con uno strumento tester chiave debole
  • Genera la coppia di chiavi del tuo client su un sistema in cui hai fatto il dovuto diligenza per assicurarsi che non ti dia chiavi deboli. Ad esempio:
    • Applica tutte le patch di sicurezza al tuo sistema operativo, in particolare quelle che risolvono problemi con il suo generatore di numeri casuali, SSH o qualsiasi libreria da cui dipende SSH.
    • Adotta misure per garantire che il sistema ha accesso a una buona fonte di entropia. (Argomento complicato.)
Potresti anche consigliare la rotazione delle chiavi come mitigazione.Qualche consiglio sugli strumenti per renderlo facile?Ad esempio, dopo aver aggiunto una nuova chiave privata, ci sono strumenti per avvisarti lato client ogni volta che usi una vecchia chiave per accedere a un sito, quindi sai che devi ancora modificare il file authorize_keys su quel server?
Comunque +1, questa è la risposta migliore in quanto esamina effettivamente quali rischi potenziali esistono e non esistono.
#4
+26
user541686
2017-02-07 12:54:40 UTC
view on stackexchange narkive permalink

No, a meno che non ne utilizzi uno univoco per servizio. Consente agli aggressori di identificarti.

Se usi la stessa chiave pubblica per il servizio A e il servizio B e la tua chiave pubblica viene trapelata per entrambi, questo collegherà i tuoi due account insieme.

Si spera che nessuno dei due servizi sia imbarazzante. Ma anche in questo caso, questo darà all'autore dell'attacco un vantaggio migliore per capire quale account hackerare un giorno, se vuole attaccarti.

L'identificazione è praticamente l'unico rischio reale di "trapelare" una chiave pubblica.
Demo su https://blog.filippo.io/ssh-whoami-filippo-io/
AilivolvuuCMT Freaky.
@Mehrdad Bella scoperta.Mi ci è voluto un momento per rendermi conto che mi aveva dato un "passato" comunque.Ha fatto eco alle chiavi pubbliche "sotto", ma non sono riuscito a trovarle.Alla fine si rese conto che ciò che aveva fatto eco non era niente, come in nessuno tentò.
#5
+12
whirlwin
2017-02-07 14:00:21 UTC
view on stackexchange narkive permalink

Esiste un leggero rischio di rivelare la tua identità se la tua chiave pubblica contiene il tuo nome host come commento alla fine, ad es. ssh-rsa C4F3B4B3 ... [email protected] . Se il tuo nome è abbastanza raro, potrebbe essere possibile identificarti.

Vedi questa domanda a cui risponde & per maggiori dettagli: Dovrei pubblicare la mia chiave SSH pubblica con user @ hostname alla fine?

Funziona per ssh auth anche se rimuovi il nome host alla fine.
Sì, funziona perché è solo un commento che può essere rimosso.Ma se dimentichi di rimuoverlo da solo prima di darlo via, può essere un problema.
Il mio nome host era 2013-iMac.local, che non è poi così personale, ma avrebbe potuto essere.
#6
+4
peterh - Reinstate Monica
2017-02-07 23:57:12 UTC
view on stackexchange narkive permalink

Sì, ma ...

Se la tua sicurezza si basa sulla riservatezza della chiave pubblica, stai facendo qualcosa di non ottimale. Non è per questo che è progettata la crittografia asimmetrica.

Tutte le risposte precedenti evidenziano alcune vulnerabilità

  • che hanno un rischio maggiore se la tua chiave pubblica è nota,
  • o mostrano qualche difesa aggiuntiva che hai è che è tenuta segreta.

In entrambi i casi, la vera ragione è che non usi la chiave pubblica per la quale è stato progettato. Ad esempio, la conoscenza della tua chiave pubblica rende possibile la tua identificazione. Questa operazione può essere gestita da pubkey nascosta, ma può essere eseguita meglio se si utilizza un meccanismo aggiuntivo (ad esempio, un livello di crittografia aggiuntivo con coppie di chiavi casuali generate automaticamente per sessione) per questa attività.

Ma, tutto può essere utilizzato anche per altri compiti, può essere anche fruttuoso, soprattutto se non siamo dalla parte difensiva.

#7
+3
mkrieger1
2017-02-07 21:16:20 UTC
view on stackexchange narkive permalink

Al momento non ho la mia directory .ssh sotto il controllo della versione. Ma salverebbe un passaggio se potessi mantenere .ssh / authorized_keys nel repository dotfile.

Anche se dovrebbe essere sicuro rendere pubblica la chiave pubblica, non credo che lo sia una buona idea:

La chiave privata è anche memorizzata nella directory .ssh e c'è il rischio che tu non stia attento a escluderla dal repository dotfile e a pubblicarla accidentalmente .

#8
+2
shellster
2017-02-08 20:31:49 UTC
view on stackexchange narkive permalink

Un ulteriore problema con la condivisione della chiave pubblica è se è stata generata in modo non sicuro. Sono usciti numerosi articoli sui modi in cui le chiavi RSA e Diffie Hellman possono essere backdoor ma per il resto sembrano perfettamente normali. In questo scenario, fornire la tua chiave pubblica fornirebbe a un utente malintenzionato tutte le informazioni necessarie per derivare la tua chiave privata.

Riferimenti:

http://kukuruku.co/ hub / infosec / backdoor-in-a-public-rsa-key https://www.cryptologie.net/article/360/how-to-backdoor-diffie-hellman-quick-explanation/

#9
+2
Marcelo Bielsa
2017-02-09 18:57:13 UTC
view on stackexchange narkive permalink

Esistono diverse minacce che puoi considerare. Uno discusso da altri rispondenti è quello di un utente malintenzionato che cerca di violare la chiave pubblica. Un'altra minaccia da considerare è che questo utente malintenzionato sostituisce le tue chiavi pubbliche con le sue. Se cambia le chiavi e tu non te ne accorgi, puoi configurare un sistema utilizzando le chiavi dell'utente malintenzionato, distribuendo così la SUA chiave pubblica di cui possiede la coppia privata.

#10
+1
J.A.K.
2017-02-07 14:18:17 UTC
view on stackexchange narkive permalink

Se RSA funziona come previsto, non dovrebbe essere un problema di sicurezza. Potrebbe rivelare un po 'di informazioni sulla tua identità, ma niente che questa domanda non mostri.

Perché?

Per AES, devi solo 256 bit perché la chiave è completamente segreta. Con RSA, stai fornendo a un avversario alcune informazioni (la chiave pubblica), ma può dimostrare che è ancora difficile da decifrare. Ma la scomposizione dei numeri diventa più veloce delle password forzate.

Semplicisticamente, due numeri primi scelti a caso sono la chiave privata e moltiplicati insieme formano la chiave pubblica. (Questo è fattibile perché i numeri primi sono abbastanza comuni). L'RSA si basa sul presupposto che riportarli ai due numeri primi sia difficile. Sono stati compiuti molti progressi negli algoritmi di fattorizzazione dei numeri e, se si presenteranno computer quantistici a tutti gli effetti, l'algoritmo di Shor rappresenterà la fine della RSA

Si prega di non downvote senza lasciare un commento sul motivo.
#11
  0
wberry
2017-02-10 23:03:44 UTC
view on stackexchange narkive permalink

In termini di teoria dei sistemi PKI, no. Il sistema è progettato per essere "sicuro", o più precisamente non più debole , quando sia l'algoritmo che la chiave pubblica sono noti al mondo.

In pratica, potrebbero esserci un po 'di esposizione a te per altri motivi. In breve, non compromettere la tua sicurezza con errori; ed è meglio creare coppie di chiavi distinte per ogni singolo scopo.

  • Se dimentichi e invii accidentalmente la chiave privata o un certificato di revoca e qualcuno lo vede, potrebbero essere usati contro di te. Effettuando il commit di qualsiasi cosa all'interno della cartella .ssh accetti il ​​rischio di un potenziale errore umano; devi stare attento. (E se ciò accade, semplicemente eliminarlo di nuovo potrebbe non rimuoverlo dalla cronologia. Non nei sistemi più diffusi di oggi. A seconda del sistema di controllo della versione, potresti avere difficoltà a eliminarlo completamente.)
  • A seconda quanto pubblico è il tuo repository e per cos'altro usi quella chiave pubblica, le parti ostili potrebbero essere in grado di monitorare l'attività svolta con quella chiave pubblica e quindi costruire una cronologia delle tue azioni. In teoria, identificarti nel processo. Campo lungo.


Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...