Va bene usare la stessa password per un login Linux e la chiave privata SSH?

Riepilogo: usare la stessa password per cose diverse è un'idea generalmente sbagliata. Tuttavia, in questo caso, dove i due usi della password controllano l'accesso alla stessa risorsa, non è male.

Quindi, se qualcuno può origliare quando sblocchi la tua chiave SSH (ad esempio guardando da dietro le spalle, o se sono riusciti a installare un keylogger), conosceranno la tua password sul tuo server. Se l'unico modo per accedere a quel server è avere un accesso fisico o tramite ssh (che ha disabilitato le password), non avere la password compromessa non importa.

Cioè, supponendo che la tua password sia solo una password di accesso. Infatti, è abbastanza comune che la tua password diventi un token di autenticazione per diventare root attraverso sudo . In tal caso, un utente malintenzionato che ottiene la password del file della chiave ssh e il file della chiave può immediatamente aumentare il proprio accesso all'account root. Se sei l'unico amministratore sul server, non importa molto, perché l'utente malintenzionato può iniettare malware nel tuo account che gli consentirà di portarlo dietro alla prossima volta che diventerai root. Se ci sono altri amministratori (o altri modi per accedere all'account di root, come un pannello di amministrazione remoto), ciò rimuove un'opportunità per i tuoi colleghi di disabilitare il tuo account compromesso.

Al contrario, se qualcuno può trovare la tua password sul tuo server, può sbloccare il tuo file di chiave ssh. Questo non è un problema se si usa quel file di chiave ssh (o più in generale quella password) per accedere a quel server. Tuttavia, se si utilizza la stessa chiave SSH per altri server, l'utente malintenzionato può accedere a questi altri server in base al proprio file di chiavi e alla relativa password. Questo rappresenta solo un guadagno se non si utilizza la stessa password sugli altri server.

Tutto sommato, l'uso della stessa password non farà molta differenza in situazioni tipiche diverse da un server con più amministratori in cui è possibile eseguire il backup su root.

Public/private key authentication is more secure than password authentication

È un po 'semplicistico. L'autenticazione della chiave pubblica utilizza due fattori (il file chiave e la password per il file chiave); questo è buono in quanto richiede più lavoro affinchè l'attaccante comprometta entrambi i fattori. Tuttavia, è anche necessario prendere in considerazione il rischio di un compromesso. Ad esempio, per una chiave ssh, un attacco attivo sul client rivelerà entrambi i fattori. Se l'utente malintenzionato ottiene una copia del file chiave, può provare a forzare la password offline, quindi la protezione tramite password su un file chiave richiede una password complessa, più potente di una password che può essere solo forzata tramite attacchi online (nota però che una password solo online può essere offline forzata bruta in alcune circostanze, ad esempio se l'utente malintenzionato si impadronisce di un backup di sistema).

L'uso di una password per ssh non è errato di per sé , se puoi garantire che non è possibile. Gli utenti tipici sono cattivi nella scelta di password non guidabili, che non sono una semplice variazione sul loro compleanno o sul nome della loro ragazza. Se hai una buona password (generata casualmente con una quantità di entropia che puoi valutare e che ti soddisfa), è possibile abilitare l'autenticazione della password se non si digita la password in un posto dove verrà ascoltata.

Quindi, se la password di accesso è solo una password di accesso, è possibile combinare una chiave pubblica ssh per comodità e resistenza alla navigazione a spalla, con una password complessa che non ricordi tenere in una cassastrong e utilizzare in privato in caso di emergenza (come la perdita del computer client e difficoltà ad accedere rapidamente ai backup). Se la tua password di accesso è doppia come sudo password, dovrai ricordarla.

Se si mantiene sempre il file chiave su un volume crittografato (accessibile solo a te), non è necessario crittografare la chiave. Ricordati di crittografare anche i backup.

Rispondere alla domanda che hai chiesto. Riutilizzare la stessa passphrase per entrambi questi scopi è ragionevole, dato che controlli sia il server Linux (dove è usato come password di accesso) sia Windows client (dove viene utilizzato per sbloccare la chiave privata SSH) e presupponendo che si mantengano relativamente sicuri entrambi i computer.

I puristi diranno che non si dovrebbe mai riutilizzare una password. In teoria, questo è un buon consiglio. Ma non tiene conto dei compromessi e non tiene conto della natura umana. Siamo umani; la nostra capacità di memorizzare password complesse e prive di significato è limitata. Una cosa è memorizzare una passphrase singola lunga e strong. È più difficile memorizzarne due - e impossibile memorizzarne 100. Se prendessimo il consiglio di "non riutilizzare mai una password" seriamente, allora avremmo bisogno di avere dozzine, possibilmente centinaia di password - e, data la natura umana, la conseguenza sarebbe che ognuna di queste password sarebbe inevitabilmente più debole. Potrebbero essere tutti brevi, o prevedibili, o leggere variazioni sulla stessa frase. E questa è probabilmente una situazione peggiore che scegliere una singola passphrase molto strong e riutilizzarla in questo scenario.

Quindi, se riesci a trovare un modo per memorizzare due passphrase diverse senza compromettere la loro forza, quella è la via più sicura. Se riesci a scriverli da qualche parte dove nessun altro avrà accesso (magari su un foglietto nel tuo portafoglio?), È perfettamente ragionevole.

Ma se ti trovi incapace di memorizzare due passphrase lunghe e forti - se ti ritrovi a stordire le passphrase, così puoi ricordarle entrambe - non è irragionevole, secondo me, usare la stessa passphrase per entrambi gli scopi. Apre alcuni rischi. Ad esempio, se qualcuno si rompe nel tuo server Linux e rompe gli hash delle password, poi irrompe nel tuo client Windows e ruba una copia crittografata della tua chiave privata, sarà in grado di decodificarlo. Oppure, se ottengono un keylogger sul tuo client Windows e sono in grado di registrare la passphrase SSH, saranno in grado di entrare nel tuo server SSH. Tuttavia, tali rischi possono essere accettabili, in cambio di avere una passphrase strong.

Una risposta ancora migliore. Tuttavia, penso che ci sia una risposta ancora migliore che potresti non aver ancora riconosciuto. Se stai usando SSH per accedere al tuo server Linux, non hai bisogno di una password per il tuo server Linux! È possibile aggiungere la chiave pubblica SSH al proprio file ~/.ssh/authorized_keys e quindi accedere utilizzando l'autenticazione a chiave pubblica. A quel punto, non è necessaria una password per l'accesso al server Linux. Ora hai solo una passphrase da ricordare: quella per sbloccare la passphrase SSH.

Personalmente, penso che questa sia la migliore risposta di tutti. L'autenticazione SSH a chiave pubblica è più sicura dell'autenticazione basata su password. Quindi, questa è la mia raccomandazione.

(OK, OK, potrebbe essere necessario avere una password per l'account di root del tuo server Linux e altri account dopo tutto.Ma ti suggerisco di scegliere una molto lunga e casuale, una che non tenterai mai di memorizzare, e poi scriverlo, sigillarlo in una busta e conservarlo in un posto sicuro, non lo userai mai, esiste solo come backup, nel caso in cui tu venissi escluso dal server. usa, non ha bisogno di essere memorizzabile, può essere lungo e strong quanto vuoi, e può essere totalmente diverso da tutte le passphrase che usi regolarmente.)

I vettori di attacco sono diversi. Gli attacchi locali non prevedono il blocco automatico, la registrazione, la segnalazione o il ritardo. Poiché una chiave verrà attaccata localmente, è necessario proteggere una chiave con una password più complessa.

Uso KeePass per memorizzare le mie passphrase, una sola password lunga e difficile per proteggere KeePass e una password diversa singola, lunga e difficile per il mio volume TrueCrypt.

Cifrò le mie chiavi private per proteggerti dagli utenti che ottengono il database delle chiavi sulla rete. TrueCrypt protegge solo il mio disco dall'accesso fisico.

Condividere le password è una cattiva abitudine.

Se disponi di privilegi di amministratore sul server di destinazione, è rischioso riutilizzare la password di accesso per passphrase chiave. Ora, a seconda della forza della passphrase / password, il rischio dovuto al riutilizzo può essere piccolo e merita il beneficio, ma c'è un rischio aggiunto.

L'intrusione di sistema riuscita include sia l'accesso di accesso AND root. Mantenendo la passphrase della chiave privata separata dalla password sys, si riduce il rischio che un intruso infligga ulteriori danni se si trova nel sistema tramite la chiave privata rubata.

Ricorda che, anche se utilizzi passphrase / password identiche, passphrase è più vulnerabile della password di sistema, semplicemente perché possono essere attaccati offline. Incredendo la tua chiave privata che utilizza le password sys, gli hacker avrebbero anche i privilegi di amministratore sul server di destinazione. Con una chiave privata rubata, gli aggressori hanno tempo e privacy dalla loro parte.

D'altro canto, accedere con una chiave privata senza riutilizzare la password di sys lascerebbe comunque l'intruso che deve attaccare la password sys da WITHIN al server di destinazione. È inoltre possibile rilevare attacchi di tipo brute-force o persino di dizionario della password di sistema / accesso, a condizione che gli strumenti di monitoraggio siano distribuiti.