Perché dovrei usare l'autenticazione a chiave pubblica per SSH?

Sto eseguendo un server SSH e sto ancora usando una semplice autenticazione con password. Ovunque legga della sicurezza, mi viene consigliato di utilizzare l'autenticazione a chiave pubblica. Ma non ottengo i vantaggi. Usarli è, ai miei occhi, insicuro o molto utile.

Naturalmente, se qualcuno prova a forzare brutalmente l'accesso al mio server SSH, la chiave pubblica è molto più potente di qualsiasi password. Ma a parte questo, è totalmente insicuro.

I consulenti sostengono principalmente che non è necessario ricordare una password. Quanto è insicuro? Quindi se qualcuno entra nel mio computer, non solo ottiene il mio computer, ma anche il mio server? Se sto usando SSH da vari client diversi, devo memorizzare le chiavi pubbliche una per ognuna di esse, il che moltiplica la possibilità che cadano in mani false. Potrei salvarli su una chiavetta USB che porto con me, ma può essere persa e il cercatore ha accesso al mio server.

Forse sono meglio servito con l'autenticazione a due fattori.

C'è qualche argomento che mi manca? Qual è il modo migliore per me?

se qualcuno entra nel mio computer, non solo ottiene il mio computer, ma anche il mio server?

Questo è potenzialmente vero comunque con i keylogger: non appena accedi al tuo server dal computer infetto, ottengono la password.

Ma ci sono 3 vantaggi per i tasti:

1) Autenticazione memorizzabile nella cache. Inserisci la passphrase una volta, esegui più comandi ssh. Questo è molto utile se stai usando qualcosa che usa ssh come mezzo di trasporto, come scp, rsync o git.

2) Autenticazione scalabile. Inserisci la passphrase una volta, accedi a più macchine . Più macchine hai, più utile è. Se hai 100 macchine, cosa fai? Non puoi usare la stessa password (a meno che non sia una clone farm) e non ricordi che molti. Quindi dovresti usare un gestore di password e sei tornato al singolo punto di compromesso. In effetti la chiave di accesso è la tua password manager.

2b) Si ridimensiona nell'altro modo se si dispone di più amministratori che utilizzano gli stessi sistemi, perché è possibile revocare le chiavi dall'utente A senza dover dire a B, C, D, E, F ... che la password è cambiata.

(Questo può essere fatto anche con singoli account e sudo, ma in qualche modo è necessario effettuare il provisioning di tali account)

3) Automazione e delega parziale. È possibile impostare SSH per eseguire un comando particolare quando si collega una chiave . Ciò consente a un processo automatizzato sul sistema A di fare qualcosa sul sistema B senza avere la piena fiducia senza password tra i due.

(È un sostituto di rlogin / rsh, che era esilarantemente insicuro)

Modifica: un altro vantaggio delle chiavi pubbliche piuttosto che delle password è lo scenario comune in cui il server è compromesso da una vulnerabilità. In questo caso, l'accesso con una password compromette immediatamente la password. L'accesso con una chiave no! Direi che questo è più comune della compromissione del desktop di origine dell'amministratore.

Se stai usando buone password, questo può essere abbastanza sicuro. Di solito limito al minimo il numero di server accessibili al pubblico e consento a SSH da IP specifici quando possibile.

Inoltre, puoi proteggere le tue chiavi con passphrase (password). Pertanto, questa passphrase deve essere inserita ogni volta che è necessario accedere ai server. Nessuno può quindi utilizzare la chiave se non viene fornita la passphrase corretta.

Ci sono post simili:

1. Posta da serverfault .
2. Posta da scambio di sicurezza di stack .
3. Posta dal superutente .

Un modo in cui l'autorizzazione a chiave pubblica è più sicura è quando l'attaccante riesce a essere man-in-the-middle (MitM) tra il tuo computer client e il server e non noti la modifica della chiave host (probabilmente perché non l'hai fatto non hanno la vecchia chiave, ad esempio perché è la prima volta che usi questo specifico computer client).

(Lo stesso vale quando l'attaccante riesce a prendere il controllo del server e ci sono altri server in cui funzionano le stesse credenziali.)

Con l'autenticazione standard basata su password, si sta inviando la password (all'interno della connessione crittografata) in testo normale, il server autentico normalmente l'hash e confronta il risultato con un hash memorizzato nel suo database delle password. Un utente malintenzionato MitM potrebbe invece prendere questa password, aprire una connessione al server reale e accedere lì ... e inoltrare i contenuti a te (quindi non noti nulla), o semplicemente fare le sue cose malvagie sul tuo server .

Con l'autenticazione con chiave pubblica, il client sta sostanzialmente firmando alcuni dati conosciuti sia dal server che dal client per dimostrare che è in possesso della chiave privata e sta inviando la firma al server. Questi dati firmati includono un identificatore di sessione, che dipende da numeri casuali scelti sia dal client che dal server, ed è quindi diverso per ogni sessione. Se MitM apre la propria connessione SSH al server reale, quella avrà un ID di sessione diverso e quindi la firma fornita dal client non funzionerà lì.

Naturalmente, come già detto in altre risposte, è necessario proteggere la propria chiave privata, ad esempio crittografata con una passphrase o possibile su un dispositivo separato che crea firme solo dopo aver inserito un PIN.

OpenSSH può mantenere la propria CA per gestire le chiavi host e client SSH e può utilizzare gli elenchi di revoche su di essi. Ciò potrebbe aumentare la sicurezza fornita dall'autenticazione basata su chiave.

Hai ragione sul reclamo "non hai bisogno di una password". Questo è davvero insicuro sul lato client.

Ciò che rende più sicure le sole chiavi pubbliche per l'accesso è il fatto che non c'è modo di forzare l'accesso forzato al server. Tutto ciò che un attaccante potrebbe ottenere è quello di caricare un po 'sul tuo server - puoi usare fail2ban per tenerlo sotto controllo.

Per motivi di sicurezza sul lato client, è necessario proteggere la chiave privata con una buona passphrase. Ovviamente ora connettersi al server è più complicato che con una password. Per ovviare a questo problema, è possibile utilizzare l' agente ssh per memorizzare la chiave privata in memoria se si intende connettersi al server più volte di seguito. È buona norma limitare il tempo di conservazione della chiave.

Forse sono meglio servito con l'autenticazione a due fattori.

Una possibilità per 2FA per SSH (e una che richiede una configurazione / complessità relativamente modesta) è in realtà l'uso di una chiave pubblica e una password.

Credo che qualcosa del genere AuthenticationMethods publickey,keyboard-interactivepossa essere aggiunto /etc/ssh/sshd_configper farlo funzionare.

Più in generale, il problema è più che le password (da sole) non sono un ottimo metodo per l'autenticazione perché sono spesso di dubbia qualità. Un 'argomento' molto semplice per chiavi vs password è che una chiave sarà generalmente di almeno 2048 bit, e spesso di più (per le chiavi EC, questa sarebbe la forza effettiva, piuttosto che la dimensione effettiva). Quei bit sono anche generati da un meccanismo crittograficamente sicuro (o appropriato).

Una password è spesso inferiore a 2048 bit e spesso non deriva da una fonte crittograficamente sicura.

Puoi anche proteggere le tue chiavi con una password, per evitare problemi legati alla loro perdita (anche se qualcuno potrebbe provare a forzare la password).

Quindi, in sostanza, le differenze possono essere rese abbastanza trasparenti tra chiavi e password e l'uso delle chiavi ti compra una password migliore di quella che un essere umano potrebbe gestire. Questo non vuol dire che sono una panacea, ma in media forniscono più sicurezza delle password.