può ssh l'autenticazione della chiave pubblica senza password va bene se combinata con una VPN?

Questa è una tipica domanda di difesa in profondità. Perché ho bisogno di X se ho già Y e Z in posizione?

La risposta comune è che la sicurezza di solito è valida quanto il suo anello più debole. Nel tuo caso, il tuo unico e unico meccanismo di sicurezza sembra essere la tua VPN. Questo è il tuo link più strong e più debole. Secondo te è sufficiente protezione e non è necessaria alcuna protezione aggiuntiva.

Forse hai ragione. Potrebbe essere abbastanza buono. A casa, ho solo un lucchetto sulla mia porta. So che due blocchi dovrebbero essere più forti, ma il costo / il problema di installare un altro blocco e dover utilizzare due chiavi non vale la pena per me. Comunque non ho molto da rubare. Ma se il mio blocco o la tua VPN venissero compromessi, allora ci rimane poca o nessuna protezione. La sicurezza VPN può essere compromessa in una varietà di scenari, alcuni di essi sono così banali come qualcuno che accidentalmente fa una stupida modifica alla configurazione che lascia aperta la tua VPN, ad esempio. Inoltre, anche se la VPN è impermeabile al 100%, un dipendente potrebbe decidere che è una buona idea collegare un router wireless alla rete in modo che possano usare l'iPhone più facilmente, lasciando la possibilità di entrare nella rete senza VPN. Dipende ovviamente dalla tua organizzazione, dal setup e così via. Il principio di base è lo stesso.

Dovresti considerare la forza / debolezza della tua protezione dal costo / valore dei tuoi dati. Quindi aggiungi il 'costo residuo' di aggiungere e gestire un altro livello di protezione e vedere se ne vale la pena. L'installazione di un altro gateway VPN, in modo da avere due VPN, potrebbe essere costoso e inefficiente. Aggiungere le password alle tue chiavi private ssh potrebbe comunque essere semplice ed economico per meritarti.

Ci sono due modi principali con cui un utente malintenzionato può ottenere il file della chiave privata:

• Compromettendo la macchina client, nel qual caso l'utente malintenzionato di solito può ottenere anche la password.
• Compromettendo un backup del computer client o rubando quella macchina.

Se stai confrontando l'autenticazione della chiave privata con l'autenticazione della password, solo il secondo caso è rilevante. Nel secondo caso è necessaria una password complessa per il file della chiave privata.

È possibile ridurre il rischio escludendo il file della chiave privata dai backup, ma sembra che si abbia un controllo limitato sulle macchine client e il furto è sempre una possibilità. È inoltre possibile ridurre il rischio avendo un modo per disattivare rapidamente una chiave. Se una penetrazione nella rete richiede una connessione VPN oltre alla chiave SSH, aumenta la finestra temporale per la disattivazione della chiave prima che si possa fare del male.

Si noti che una password non è una panacea neanche. I client SSH tendono a rendere l'autenticazione della password difficile da automatizzare, ma gli utenti sufficientemente infastiditi scriveranno comunque la password in un file di testo normale e potrebbero persino esporlo in uno script o in un file di configurazione da qualche parte. L'uso di un file di chiave privata ha il vantaggio che le informazioni riservate sono concentrate in un file che gli utenti non tendono a copiare.

Un'altra considerazione che è a vantaggio delle chiavi private è che tendono ad essere più facili da revocare, da un punto di vista sociale. Dire a un utente che devono cambiare la propria password non è mai apprezzato e non si ha modo di assicurarsi che non cambieranno da Password123 a Password456 . (A meno che non imposti le password, nel qual caso sai che l'hanno scritto da qualche parte.)

Inoltre, se la VPN ha la stessa password di SSH, per la maggior parte degli intenti SSH non esegue alcuna autenticazione aggiuntiva. Pertanto SSH con autenticazione chiave rappresenta un ulteriore livello di sicurezza in questo scenario (indipendentemente dal fatto che la chiave sia ben protetta), mentre SSH con la stessa password no. Se l'alternativa è avere la password per farti passare attraverso la porta posteriore e la porta d'ingresso, avere la backdoor protetta da un meccanismo diverso è un vantaggio.

La tua domanda ruota attorno all'archiviazione delle chiavi private e non al meccanismo di autenticazione ssh.

Quindi, alle risposte:

1. Sì, il meccanismo e il protocollo delle chiavi private / pubbliche ssh sembra essere sicuro.
2. Sì, la chiave privata deve essere crittografata tramite una passphrase complessa (particolarmente importante se memorizzata sul computer client).
3. Questo non ferma tutti gli attacchi, solo alcuni.
4. Sono necessarie difese stratificate.
5. Questo non è un problema particolarmente importante per quanto riguarda gli altri problemi che potrebbero essere ignorati nell'architettura di sicurezza (e no non lavoro nello stesso posto che fai, semplicemente estrapolando).

Prima di tutto, le chiavi SSH sono categoricamente migliori delle password ssh:

• Non puoi ragionevolmente forzare la forza bruta su una chiave SSH. Con le password, puoi ottenere un fortunato successo indovinando "changeme" o "12345" o "nicole". Le chiavi, d'altra parte, sono costituite da 2048 bit pseudo-casuali. Non vale nemmeno la pena nemmeno provarci.

• Le chiavi SSH utilizzano la crittografia asimmetrica per impedire la divulgazione di eventuali segreti . Se ti connetti utilizzando la password auth a un server SSH malevolo, fornirai loro il tuo nome utente e la password, che potrebbero utilizzare per tutti i tipi di attacchi. Perpetrare un attacco contro qualcuno che usa l'autenticazione basata su chiave è molto più difficile. ( Non sono nemmeno sicuro che sia possibile, ci sono esempi di questo?)

• L'accesso alle chiavi SSH può essere revocato o esteso su base per utente anziché su base per account.

• Le chiavi SSH possono essere utilizzate per implementare sicurezza aggiuntiva o restrizioni per utente oltre a quelle disponibili tramite password.

• Puoi utilizzare la stessa chiave per accedere a più server senza una significativa riduzione della sicurezza.

• Le chiavi SSH ti permettono di fare cose davvero interessanti come forwarding degli agenti , che è assolutamente la cosa più bella di sempre (non lamentarmi delle implicazioni sulla sicurezza dei server ostili: è fantastico. La-la-la-la non ascoltare).

Rispetto alle chiavi client crittografate o non crittografate; questa è una questione di gusti personali e politica. Se non vi è alcuna possibilità che la tua chiave privata vada a finire, allora non crittografata va bene. Ma davvero, con la chiave agenti , non c'è motivo per non crittografarlo e la sicurezza aggiunta è benvenuta.

Infine, e questo è probabilmente saliente qui, SSH con autenticazione basata su chiave è più sicuro rispetto alla maggior parte dei sistemi VPN , in particolare perché le reti VPN generalmente utilizzano l'autenticazione basata su password e non hanno alcuna protezione integrata contro gli attacchi man-in-the-middle. ^{Nota: alcune VPN hanno utilizzato l'autenticazione bidirezionale basata su chiave. Quelli sono sicuri almeno quanto SSH.}

Quindi il fatto che tu stia usando una VPN migliore di quella che usi per costruire la VPN stessa è sottilmente ironico. E la tua difesa dell'autenticazione basata su chiave basata sulla sicurezza della VPN in allegato lo è ancora di più.

Nota:
Gran parte di quanto sopra è orientata all'idea di utilizzare le chiavi ssh per le sessioni interattive piuttosto che per i sistemi automatici come i backup programmati, ecc. Tuttavia, il confronto con altre tecnologie rimane valido a prescindere. Qualsiasi riduzione della sicurezza con un sistema hands-off (senza password) per quanto riguarda la sicurezza delle chiavi si applica tanto alla memorizzazione della password o chiave VPN sul sistema quanto alla memorizzazione della chiave SSH non crittografata. Memorizzare le credenziali non è mai sicuro, ma una chiave SSH memorizzata è sempre più sicura di una password memorizzata a causa della tecnologia asimmetrica e della resistenza agli attacchi di rete.