L'uso di una coppia di chiavi pubblica / privata è abbastanza conveniente per accedere agli host frequentati, ma se sto usando una coppia di chiavi senza password, è più sicura (o meno sicura) di una password? La sicurezza attorno al mio file di chiavi private è fondamentale, ma il mio file di chiave privata magico era solo un elenco di password per vari host, c'è una differenza?
La mia risposta è che l'uso di coppie di chiavi pubbliche è una cosa molto più intelligente da fare rispetto all'utilizzo di password o elenchi di password. Mi concentrerò su cose che sono non ampiamente conosciute su diverse forme di autenticazione SSH e non vedo altre risposte che le menzionino.
Prima di tutto, devi capire che l'autenticazione dell'utente è un processo diverso e separato rispetto alla creazione del canale sicuro . In parole povere ciò significa che per prima cosa viene utilizzata la chiave pubblica del server (se accettata!) Per costruire il canale SSH sicuro, abilitando la negoziazione di una chiave simmetrica che verrà utilizzata per proteggere la sessione rimanente, abilitare il canale riservatezza, protezione dell'integrità e autenticazione del server.
Dopo il canale è funzionale e sicuro, l'autenticazione dell'utente avviene. I due modi usuali per farlo sono usando una password o una coppia di chiavi pubbliche. L'autenticazione basata su password funziona come puoi immaginare: il client invia la sua password tramite il canale protetto, il server verifica che questa sia effettivamente la password dell'utente specifico e consente l'accesso. Nel caso delle chiavi pubbliche, abbiamo una situazione molto diversa. In questo caso, il server ha la chiave pubblica dell'utente memorizzata. Quello che succede dopo è che il server crea un valore casuale (nonce), lo crittografa con la chiave pubblica e lo invia all'utente. Se l'utente è chi dovrebbe essere, può decodificare la sfida e inviarla al server, che conferma l'identità dell'utente. È il classico modello di risposta alla sfida . (In SSHv2 è effettivamente usato qualcosa di diverso ma concettualmente vicino)
Come puoi immaginare, nel primo caso la password viene effettivamente inviata al server (a meno che SSH non utilizzi la password challenge response), nel secondo la tua chiave privata non abbandona mai il client. Nello scenario immaginario che qualcuno intercetta il traffico SSL ed è in grado di decrittografarlo (utilizzando una chiave privata del server compromessa, o se si accetta una chiave pubblica errata durante la connessione al server) o ha accesso al server o al client, la password sarà noto - con l'autenticazione della chiave pubblica-privata e il modello di risposta alla sfida i tuoi dettagli privati non cadrà mai nella mano dell'attaccante. Quindi, anche se un server a cui ti colleghi è compromesso, altri severs usi la stessa chiave per non essere!
Ci sono altri vantaggi nell'usare una coppia di chiavi pubbliche: la chiave privata non deve essere archiviata in chiaro nel PC client come suggerito. Questo ovviamente lascia aperto il file della chiave privata al compromesso come farebbe un file di password non crittografato, ma è più facile decrittografarlo (all'accesso) e utilizzare la chiave privata. Dovrebbe essere memorizzato crittografato e devi fornire una passphrase solitamente lunga per decrittografarlo ogni volta che viene utilizzato.
Ovviamente questo significa che dovrai fornire la passphrase lunga ogni volta che ti connetti a un server, per sbloccare la tua chiave privata - Ci sono dei modi per aggirare questo problema. È possibile aumentare l'usuabilità del sistema utilizzando un agente di autenticazione: questo è un software che sblocca le chiavi per la sessione corrente, quando si accede a gnome per esempio o quando si esegue prima ssh nel client, quindi è possibile digita "ssh remote-system-ip" ed esegui l'accesso, senza fornire una passphrase, e fallo più volte fino alla disconnessione dalla sessione.
Quindi, per riassumere, l'utilizzo di coppie di chiavi pubbliche offre una protezione notevolmente maggiore rispetto all'utilizzo di password o elenchi di password che possono essere acquisiti se il client , il server o la sessione sicura è compromessa . Nel caso in cui non si utilizzi una passphrase (che non dovrebbe accadere), le coppie di chiavi pubbliche ancora offrono protezione contro server e sessioni compromesse.
Rispetto a un elenco memorizzato di password (lunghe e casuali), una chiave privata SSH memorizzata offre la stessa sicurezza : le cose sono al sicuro finché il tuo file privato rimane privato.
La chiave privata, tuttavia, è molto più conveniente , sia praticamente (in questo momento, i client SSH lo supportano immediatamente, contrariamente a un file personalizzato di password che devi utilizzare con copia e incolla manuali) e teoricamente (è possibile riutilizzare la stessa chiave per ciascun host a cui ci si vuole connettere, mentre un elenco di password crescerà linearmente con il numero di host contattati, a meno che non si riutilizzi la stessa password per più host , che è cattivo ).
Dipende dalle minacce che consideri.
Il punto principale dell'autenticazione della chiave pubblica / privata non è quello di lasciare il tuo segreto, anche alla parte che stai autenticando. Per questo motivo, l'utilizzo delle chiavi è migliore, poiché non invii mai il tuo dispositivo segreto all'esterno del tuo computer.
Tuttavia, se la minaccia che consideri è locale e se non proteggi le tue chiavi private con una password, la memorizzazione di un elenco di password in chiaro è quasi la stessa cosa che memorizza le chiavi private senza protezione.
Per questo motivo, è utile proteggere le tue chiavi private con una password e utilizzare strumenti come ssh-agent (per comodità). Su OSX, questo può anche essere integrato con il KeyChain, in modo che non sia nemmeno necessario sbloccare la chiave privata (a livello di applicazione, solo a livello di daemon di sicurezza) per poterla usare tramite SSH (essenzialmente, il KeyChain e il demone di sicurezza si prendono cura di ssh-agent).
La principale differenza tra l'utilizzo di una chiave privata senza password e l'uso della password di testo semplice per l'autorizzazione SSH è l'autorizzazione di qualcosa che hai (il tuo chiave privata) o qualcosa che conosci (la tua password memorizzata). Sono di razza diversa, ma è difficile dire che uno è in definitiva migliore o più sicuro.
L'autorizzazione di qualcosa che hai è normalmente più difficile per l'attaccante di replicare al di fuori del blu: è più facile forzare / indovinare la tua password più semplice che replicare la tua chiave. Ma ha un grosso svantaggio: ora mantenere la tua chiave privata davvero segreta diventa fondamentale . Se usi qualcosa che conosci solo (password memorizzata), dovrebbe essere più facile mantenerlo in quel modo (almeno in teoria). Ma se devi memorizzarlo, probabilmente usi qualcosa di non complesso.
Quindi è per te che devi decidere, cosa è più probabile, che la tua chiave privata strong venga rubata o non provata con una password così strong (o acquisita in altro modo).
C'è un'eccezione qui - se intendi nella tua domanda che memorizzerai password molto lunghe, complesse e casuali nel tuo file segreto invece di usare una chiave privata, allora c'è probabilmente poca differenza tra i due ancora qualche differenza (mi è mancata la parte, vedi la risposta di @john per una bella recensione su questo ). In questo caso entrambi sono qualcosa che hai , mantieni i tipi segreti, ma quindi chiedi a te stesso - perché farlo in primo luogo se è questo che sono state progettate le chiavi private per? dovresti stare con le chiavi private in quel caso.
Il documento di riferimento sta discutendo le password digitate all'interno di una sessione ssh; Penso che, e i commenti di Richard, valga la pena di tenersi in giro, ma non credono più nella risposta stessa. (Continuo a preferire le chiavi pubbliche.)
Song, Wagner e Tian hanno dimostrato che è È possibile velocizzare le ricerche di password a forza bruta circa 50 volte utilizzando informazioni di temporizzazione da ssh sessioni . Noack ha rivisitato il loro studio e ha trovato SSH2 vulnerabile anche all'analisi dei tempi.
L'attacco fa due presupposti:
Le chiavi pubbliche non sono solo più comode, ma più sicure contro determinate minacce.
Se si utilizzano i tasti "software" (ovvero le chiavi memorizzate nella directory .ssh o equivalente) si è fondamentalmente sullo stesso livello di memorizzazione delle password.
OpenSSH ora ha un supporto PKCS # 11 quasi decente, lo stesso è disponibile in KiTTY (una forchetta PuTTY), quindi per fare veramente uso dell'autenticazione pubkey, optare per una smart card. Quindi c'è una vera differenza dalle password. Un file di chiavi del software, protetto da una password, può essere replicato allo stesso modo di una password semplice, mentre una smart card non può.
Leggi altre domande sui tag authentication cryptography ssh key-management