Perché l'autenticazione con chiave SSH è migliore dell'autenticazione con password?


45

Questa non è una domanda tanto tecnica quanto concettuale. Comprendo che la crittografia utilizzata in una chiave SSH è molto più potente di una normale password, ma non capisco perché sia ​​considerata più sicura.

La maggior parte dei tutorial che ho letto suggeriscono di utilizzare l'autenticazione con chiave SSH anziché l'autenticazione con password. Ma la mia comprensione è che chiunque abbia quindi accesso a una macchina client pre-approvata sarà quindi in grado di connettersi al server, il che significa che il livello di sicurezza fornito dalla chiave SSH è forte solo quanto il livello di sicurezza del fisico macchina client.

Ad esempio, se imposto una chiave SSH sul mio telefono per connettermi al mio computer di casa, se dovessi perdere il mio telefono e qualcuno riuscisse a sbloccarlo, potranno connettersi al mio computer di casa. So che posso quindi rimuovere la chiave del mio telefono dal mio computer di casa, ma sono vulnerabile fino a quando mi rendo conto che il dispositivo client è stato perso / violato.

Ho frainteso qualcosa o sono valide preoccupazioni?


10
Fai entrambe le cose: una chiave che richiede una password. In questo modo è necessario identificare due cose, non solo una. Puoi anche invalidare le chiavi perse abbastanza facilmente e avere più chiavi autorizzate per un maggiore controllo su questo, e così via.
Phoshi,

2
Questo dovrebbe probabilmente essere spostato in sicurezza.

10
@DKGasser: No, non dovrebbe. È una domanda perfettamente valida qui. Solo perché qualcosa può essere spostato in un altro sito SE non significa che dovrebbe .
Wuffers,

4
@DKGasser: potrebbe andare su quel sito, è una domanda perfettamente valida lì. Ma è anche una domanda valida qui, quindi non c'è motivo di migrarla. Se questa domanda dovesse essere messa fuori tema qui, quindi sì, potrebbe essere migrata lì. Ma è totalmente in tema su questo sito e quindi non dovrebbe essere migrato.
Wuffers,

3
E non dimenticare, la chiave SSH non passa mai attraverso la rete. Il server remoto non ottiene MAI la chiave, al contrario di una password, che non viene solo inviata sulla rete, ma inviata al server remoto. Pensaci la prossima volta che non sei sicuro di quale password utilizzare e prova alcuni ... che potrebbero essere utilizzati su altri account! Quali password hai inviato a quel server ???
9mjb

Risposte:


40

Se il tuo servizio SSH consente l'autenticazione basata su password, il tuo server SSH connesso a Internet verrà martellato giorno e notte dalle reti bot che tentano di indovinare nomi utente e password. La rete bot non ha bisogno di informazioni, può semplicemente provare nomi popolari e password popolari. Ci sono moltissime persone che si chiamano john con una password di qwerty123. A parte tutto ciò, questo ostruisce i tuoi registri.

Se il servizio SSH consente solo l'autenticazione con chiave pubblica, un utente malintenzionato necessita di una copia di una chiave privata corrispondente a una chiave pubblica memorizzata sul server. Non possono semplicemente effettuare attacchi casuali, devono avere una conoscenza preliminare dei tuoi utenti e devono essere in grado di rubare una chiave privata dal PC di un utente autorizzato del tuo server SSH.

Il fatto che le chiavi private siano spesso protette da una lunga passphrase ha un significato secondario.

Aggiornare:

Come sottolineato dai commenti, e come ho sperimentato, lo spostamento del servizio SSH dalla porta 22 a una porta con numero elevato fa una notevole differenza nel numero di tentativi di accesso non autorizzati che compaiono nei registri. Vale la pena farlo, ma lo considero una forma di sicurezza per oscurità (un falso senso di sicurezza) - prima o poi le botnet implementeranno una scansione delle porte furtiva e silenziosa o verrai deliberatamente preso di mira. Meglio essere preparati.

Uso sempre una passphrase lunga per proteggere la mia chiave privata, suppongo che questo sia di particolare importanza sui dispositivi mobili che potrebbero essere più facilmente persi o rubati.

Inoltre, http://xkcd.com/538/

Sicurezza


7
+1 tranne che l'autent a chiave pubblica non farà nulla per intasare i tuoi log con i robot che tentano di connettersi. Per fermarlo, esegui il tuo server SSH su una porta alta (cioè 9876 anziché 22). Quindi se vogliono colpirti devono prima portarti in scansione, e generalmente i robot non perdono molto tempo ... ci sono molti server SSH il 22.
Ex Umbris,

3
Non stai scherzando sulla dimensione del registro - my / var / log / secure è passato da megabyte di tentativi di accesso a kilobyte (con solo i miei record di accesso).
Giovanni C,

2
+1 Interessante, ho eseguito l'autenticazione basata su password per .. come 10 anni ormai .. lol .. Concesso, le mie porte ssh esposte pubblicamente non sono mai la porta 22. Pensa che le botnet mi effettueranno la scansione e cercherò di entrare in ogni porto possono ?? Buone informazioni, grazie.
James T Snell,

2
@ExUmbris piuttosto che cambiare la porta che dovresti considerare usando fwknop: Single Packet Authorization e Port Knocking . Il vantaggio qui dovrebbe essere ovvio: quando non si consente a nessuno di vedere nemmeno che la porta è aperta da nessuna parte a meno che non gli sia stato dato l'accesso alla porta bussando con SPA, allora non possono nemmeno tentare di trovarla con nmap e sfruttalo. È molto meglio della semplice sicurezza attraverso l'oscurità.
aculich,

@aculich Cambiare la porta non è "sicurezza attraverso l'oscurità". Tutto quello che sto facendo è impedire ai log di riempirsi di avvisi. Tuttavia, hai un punto valido sul miglioramento della sicurezza con SPA.
Ex Umbris,

8

La logica è che ci sono molte più combinazioni di chiavi SSH rispetto alle password, quindi è molto più difficile da indovinare. L'uso delle chiavi SSH consente inoltre di disabilitare l'autenticazione con password, il che significa che la maggior parte degli attacchi automatici che attraversano Internet saranno inutili.

Per quanto riguarda la sicurezza fisica, non esiste alcuna differenza tra il salvataggio di una password e la presenza di una chiave SSH non crittografata sul dispositivo in caso di smarrimento o furto. L'unico vantaggio che potresti avere è che nessuno ha la tua password e in teoria potresti assicurarti che tutti i dispositivi abbiano certificati SSH diversi in modo da poter disabilitare solo quello per il tuo telefono.

Credo che sia anche possibile proteggere con password le chiavi SSH.


Vale la pena notare, tuttavia, che i tentativi di forzare la password contro sshd possono essere rilevati e protetti contro (ad esempio da fail2ban), mentre qualcuno che ha rubato la chiave privata può provare le password su di essa velocemente come il loro computer (o cluster) lascerà loro. Questo non è ancora un grande attacco , ma hanno migliorato drasticamente le loro probabilità rispetto a una ragionevole politica fail2ban.
Xiong Chiamiov,


1

Le password possono anche essere compromesse dal monitoraggio della tastiera "a spalla". Inoltre, l'utilizzo di password simili in molti luoghi è un punto debole, soprattutto se la password viene talvolta utilizzata su un computer meno sicuro con potenziali keylogger.

Hai ragione sul fatto che una chiave non crittografata può essere letta dal disco rigido se il computer viene rubato, quindi crittografalo con una password.

Se il tuo computer è compromesso da malware, sei comunque pieno ... - qualcuno può ottenere la chiave crittografata e keylog la tua password.


1
Nota: ma non è possibile crittografare la chiave con una password se deve essere utilizzata a livello di codice (ad es. In uno script).
TheStoryCoder
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.