it-swarm.dev

Gli accessi SSH senza password sono più sicuri?

Ho discusso a lungo con i miei colleghi se l'autenticazione SSH basata su chiavi (in particolare per OpenSSH) è più sicura dell'autenticazione tramite password. I miei colleghi si collegano sempre ai server con password, mentre preferisco accedere a un sistema senza dover inserire una password ogni volta.

Temono che non sia sicuro connettersi senza una password. Cosa dovrei dire loro? Per me, le password sono cattive perché potrebbero essere forzate o catturate con un keylogger.

Io uso il ssh-copy-id strumento per copiare la mia chiave pubblica sul server. Quindi mi collego semplicemente con ssh servername. In effetti, devo solo inserire la password per la mia chiave privata na volta ogni volta che il mio sistema si avvia. Se la mia workstation funziona per 3 giorni, non devo mai più inserire la password, che dicono non è sicura. È vero? So che le chiavi sono migliori, ma non so come spiegarglielo.

68
Daniel

L'accesso basato su chiave è considerato molto più sicuro degli accessi basati su password quando si guarda dalla prospettiva di un tentativo di forza bruta di ottenere l'accesso da un sistema di terze parti: le possibilità di craccare una chiave sono effettivamente zero, mentre le password errate sono fin troppo comuni.

Dal punto di vista di un sistema client compromesso (la tua stazione di lavoro), non ci sarà alcuna differenza perché se gli attaccanti possono ottenere la tua chiave privata e/o dirottare una sessione, potrebbero probabilmente anche installare una sorta di key logger, rendendo il percepito vantaggio di password inutili.

54
Sven

È sicuro come il tuo computer. La chiave è seduta, non crittografata, nella RAM; un utente malintenzionato con accesso fisico al computer o accesso remoto remoto potrebbe ottenerlo.

Pensaci come se i tuoi colleghi usassero un programma sicuro per password e lo lasciasse sullo schermo con il database disponibile senza l'immissione della password; se blocchi la tua workstation quando ti allontani e la tieni al sicuro da attività remote ostili, allora è ragionevolmente sicura, ma un attacco congelato RAM potrebbe ancora teoricamente ottenere la chiave.

Ma qualcuno in quelle posizioni potrebbe facilmente installare anche un keylogger, come hai sottolineato. Fintanto che stai attento alla sicurezza della tua workstation, non lo definirei meno sicuro delle password; ma i reali vantaggi degli accessi basati su chiavi sono in realtà la protezione contro, ad esempio, attacchi di password a forza bruta contro il server (poiché le chiavi sono quasi impossibili a forza bruta).

25
Shane Madden

In realtà i tuoi colleghi hanno ragione. Pensa a questo ... Le tue postazioni di lavoro si rompono, è attivo da un paio di giorni e ora gli hacker hanno creato l'intera rete perché non usi una passphrase ssh.

Detto questo, le password condivise non sono mai buone e rappresentano un grave punto debole del sistema. Presumo che tu stia parlando dell'accesso alla radice.

Il punto che sto sottolineando è che entrambi hanno degli svantaggi e dove la sicurezza deve essere un luogo.

Per tutti i server che gestisco utilizzo una chiave SSH passphrase. Questo mi dà il meglio di entrambi i mondi. Solo una password che conosco e non utilizzo una password condivisa per altri utenti.

(e sì, ho visto dove è stata usata una chiave ssh passphraseless per compromettere e l'intera rete.

12
Squidly

Sei sicuro solo quanto il tuo anello più debole. Se i tuoi server remoti consentono sia l'autenticazione basata su password che su chiave, sei meno sicuro rispetto a permetterne solo uno.

Le tue vulnerabilità extra per un sistema basato su chiave tramite Password Authentication (PA) sono:

  1. Un utente malintenzionato ottiene una copia della chiave privata protetta da passphrase dicendo di avere accesso fisico a un disco non crittografato su qualsiasi sistema (ad esempio, avviare in modalità utente singolo), quindi esegue un attacco di forza bruta offline basato su GPU sulla chiave e quindi ottiene accesso a tutti i sistemi se la passphrase è adeguatamente debole (ad es. 4 parole da dadi).

  2. Usi qualcosa come ssh-agent che mantiene la tua passphrase o chiave privata in memoria per un uso successivo e un attaccante è in grado di toglierla dal tuo sistema in qualche modo (ad esempio, un altro utente root è stato loggato mentre avevi la password in memoria).

  3. La tua chiave era molto meno sicura di quanto pensassi. Ad esempio, la debolezza chiave di OpenSSH; dove l'unica casualità è venuta dal id processo così sono state generate solo 65536 chiavi. Mentre questo tipo di problemi si spera vengano notati e patchati rapidamente, come utente finale è impossibile dire che non ce ne sono grave difetto nel generatore di numeri casuali utilizzato per creare le tue chiavi.

La tua sicurezza extra dall'utilizzo dell'autenticazione basata su chiave:

  1. Gli attacchi di forza bruta sono impossibili durante la vita dell'universo, senza rubare la tua chiave privata (e se fosse protetta da passphrase; quindi rompere la passphrase).
  2. Gli attacchi MITM non funzioneranno (un host remoto dannoso non riesce a capire la tua chiave privata/passphrase); sebbene ssh avvisi già agli attacchi MITM di avvisare gli amministratori usando le chiavi Host e known_hosts File.

In pratica entrambi sono altrettanto sicuri. Chiunque può rubare chiavi private ssh dalla RAM, può installare un keylogger e ottenere password/passphrase/chiavi private.

Personalmente, mi piace la tua soluzione poiché una passphrase è più conveniente (memorizzata nella RAM; su una macchina a un utente che si blocca dopo 5 minuti); anche se ho ancora messo la mia chiave privata protetta da passphrase su macchine locali di cui sono l'unico utente.

9
dr jimbob

Una delle ragioni per cui credo che l'autenticazione basata su chiave abbia un leggero vantaggio in termini di sicurezza è che ci sono volte in cui ho visto entrambi gli utenti finali e anche a volte ho inserito la mia password in un campo nome utente anziché nella finestra di dialogo password ( a seconda del client ssh). Oppure premi il tasto invio troppo rapidamente e il client ssh si chiude e la mia password passa alla cronologia del mio terminale.

Se non si presta attenzione ogni volta che si immette la password, è possibile che la password venga aggiunta in chiaro eventualmente a diversi file di registro, potenzialmente alla cronologia di Shell o persino a un qualche tipo di cavallo di Troia. Nel caso di una chiave senza password o di una chiave che carichi con un agente SSH all'inizio della sessione, non dovresti mai riscrivere la password, quindi è improbabile che tu digiti le tue credenziali in un posto sbagliato e mostri il tuo password per qualcuno o qualcosa che non intendevi.

6
Zoredache

Beh, in un certo senso sono i 6. Il primo rischio immediato per la sicurezza di un accesso basato su password sarebbe un utente non autorizzato che ottiene (con qualsiasi mezzo) la password per il server. Allo stesso modo, un accesso basato su chiave ha il rischio per la sicurezza che un utente non autorizzato ottenga l'accesso al tuo computer. Se si utilizza una password complessa sul server, si corre il rischio che gli utenti delle password debbano scriverla da qualche parte per ricordarla. Con gli utenti chiave, si corre il rischio che si allontanino dalla propria scrivania con il computer sbloccato.

Molto dipende dal rapporto rischio/usabilità. Ovviamente potresti richiedere password sulle chiavi, consentire solo determinati indirizzi IP in base alla chiave e qualsiasi altro numero di misure di sicurezza a prova di blocco, ma ciò rende le persone infelici.

Ma per rispondere alla tua domanda: se stiamo parlando di una configurazione Vanilla di OpenSSH, gli accessi basati su password e basati su chiavi hanno entrambi i loro punti deboli di sicurezza diversi.

5
Safado

Disattivo sempre l'accesso tramite password su ssh per root sui miei sistemi. In questo modo, non è possibile che un utente malintenzionato possa tentare di forzare la password in modo bruto.

Dovresti comunque diffidare della sicurezza sui sistemi client. Potresti voler far dimenticare all'agente ssh le tue credenziali chiave quando si accende la schermata di blocco. Ciò contribuirebbe a impedire che gli attacchi al computer client compromettano la chiave.

5
Jeff Strunk

Alcune risposte decenti qui, ma tutte sembrano mancare il segno a mio avviso.

L'uso di una coppia di chiavi per l'autenticazione sta sostituendo il "qualcosa che conosci" di un sistema basato su password con un "qualcosa che hai" di un sistema chiave o token. Torna a questo in un secondo.

Le chiavi sono molto più complesse. Penso che la maggior parte delle implementazioni SSH siano impostate sulla chiave RSA 2048. Confronta quello con una password di 8 caratteri. Anche se con hash in 256 bit, le password, perché prive della casualità delle chiavi, possono essere forzate. Schneier ha alcune grandi osservazioni su questo; anche le password presumibilmente "buone" tendono ad essere solo una combinazione di dati crackabili (una parola con un numero e forse alcune semplici sostituzioni); noi umani siamo troppo prevedibili.

Quanto a una chiave sicura quanto la password per accedere, ciò non è del tutto corretto. Se si avvolge una chiave con un'altra password, si migliora notevolmente la sicurezza poiché si utilizza essenzialmente l'autenticazione a due fattori; per accedere a qualcosa che hai (la chiave) devi usare qualcosa che conosci (una password). Sì, l'utilizzo della password di accesso per racchiudere una chiave comprometterebbe ciò.

Quindi, per il poster originale, direi che sia tu che i tuoi colleghi avete torto. Potresti essere meno di quello che sono, ma la risposta giusta è che dovresti usare sia una chiave che una password.

3
JoePete