Perché l'autenticazione con password SSH è un rischio per la sicurezza?

68

La maggior parte delle guide per la configurazione di OpenSSH consiglia di disabilitare l'autenticazione con password a favore dell'autenticazione basata su chiave. Ma a mio avviso l'autenticazione con password ha un vantaggio significativo: la possibilità di connettersi da qualsiasi luogo senza chiave. Se utilizzato sempre con una password complessa, ciò non dovrebbe costituire un rischio per la sicurezza. O dovrebbe?

— Septagram
fonte

2

Le password sono autenticazione a un fattore che può essere annusata, indovinata e riprodotta. Le chiavi sono (possibilmente) due fattori. Essere in grado di accedere da qualsiasi luogo con un solo fattore è inaccettabile su alcuni sistemi.

— Alex Holst,

25

Ci sono pro e contro per l'autenticazione basata su chiave o pw.

In alcuni casi, ad esempio, l'autenticazione basata su chiave è meno sicura dell'autenticazione con password. In altri casi, è basato su pw che è meno sicuro. In alcuni casi, uno è più conveniente, in altri meno.

Tutto si riduce a questo: quando si esegue l'autenticazione basata su chiave, è necessario proteggere la chiave con una passphrase. A meno che tu non abbia ssh-agent in esecuzione (ssh-agent ti libera di inserire la tua passphrase ogni volta), non hai guadagnato nulla in termini di convenienza. La sicurezza è discutibile: il vettore di attacco ora è passato dal server a TE, o al tuo account o alla tua macchina personale, (...) - quelli potrebbero essere o meno facili da spezzare.

Pensa fuori dagli schemi quando decidi questo. Se guadagni o perdi in termini di sicurezza dipende dal resto del tuo ambiente e da altre misure.

modifica: Oh, ho appena visto che stai parlando di un server di casa. Ero nella stessa situazione, "password" o "chiavetta USB con la chiave" sempre con me? Ho optato per il primo, ma ho cambiato la porta di ascolto SSH in qualcosa di diverso da 22. Ciò impedisce a tutti quei fanatici di script lame bruti forzando intere gamme di rete.

— romano
fonte

Cambiare la porta SSH da 22 potrebbe non essere una buona idea in molti casi. adayinthelifeof.nl/2012/03/12/…

— Tymek

75

L'uso dei tasti ssh ha una funzione unica rispetto all'accesso con password: è possibile specificare i comandi consentiti. Questo può essere fatto modificando il ~/.ssh/authorized_keysfile sul server.

Per esempio,

command="/usr/local/bin/your_backup_script.sh", ssh-rsa auiosfSAFfAFDFJL1234214DFAfDFa...

consentirebbe solo il comando `/usr/local/bin/your_backup_script.sh" con quella chiave particolare.

È inoltre possibile specificare gli host consentiti per la chiave:

from="yourclient,yourotherclient", ssh-rsa auiosfSAFfAFDFJL1234214DFAfDFa...

O combina i due:

from="yourbackupserver", command="/usr/local/bin/your_backup_script.sh", ssh-rsa auiosfSAFfAFDFJL1234214DFAfDFa...

Con le chiavi puoi anche concedere un accesso temporaneo ad alcuni utenti (ad esempio un consulente) a un server senza rivelare la password per quel particolare account. Dopo che il consulente ha terminato il proprio lavoro, la chiave temporanea può essere rimossa.

— Janne Pikkarainen
fonte

Suggerimento molto molto utile.

— Sachin Divekar,

3

Inoltre, usare le chiavi è come avere una lunga password di 2000 caratteri (anche tecnicamente è ancora più robusta) rispetto a ciò che è possibile digitare manualmente in un terminale: D

— Abhishek Dujari

3

Due consigli molto utili sull'autenticazione SSH, ma in realtà non risponde alla mia domanda ...

— MikeMurko,

Se si desidera forzare un utente autenticato con password a passare un comando specifico, modificare la shell di accesso. Inoltre, "concedere l'accesso temporaneo senza rivelare la password" è una pessima idea. Esistono centinaia di modi diversi per mantenere l'accesso per dopo.

— b0fh

Solo l'ultimo paragrafo risponde alla domanda IMO: i tasti consentono la revoca granulare, mentre con le password devi informare tutti che lo stai modificando.

— Riking

48

Puoi ottenere il meglio da entrambi i mondi consentendo solo l'autenticazione della password all'interno della tua rete. Aggiungi quanto segue alla fine del tuo sshd_config:

PasswordAuthentication no
Match Address 10.0.0.0/8,172.16.0.0/12,192.168.0.0/16
    PasswordAuthentication yes

— MikeyB
fonte

7

Hai parzialmente risposto alla tua domanda: maggiore è il numero di posti in cui un utente malintenzionato può connettersi, più possibilità ha di penetrare nel tuo server tramite bruteforcing (considera DDoS).

Confronta anche la lunghezza della tua password con la dimensione della chiave (di solito migliaia di bit).

— Martin Vejmelka
fonte

4

96 bit di entropia significa una password di 80 caratteri, se è scritta in inglese; 15 caratteri se è casuale senza senso dal set di caratteri stampabile. sei abbastanza sicuro che le tue password ssh siano così lunghe / forti?

— MadHatter,

3

Se disponi di più password con 96 bit di entropia che non saranno vulnerabili agli attacchi del dizionario, probabilmente dovrai comunque utilizzare una sorta di software di gestione delle password, quindi perdi effettivamente l'elemento accessibile ovunque dell'uso delle password .

— Nick Downton,

5

@SachinDivekar sono 96 bit di entropia solo se si utilizzano password casuali dall'insieme [a-zA-Z], non se si tratta di parole inglesi.

— Jaap Eldering,

16

@NickDownton - Puoi avere una bella password lunga senza ricorrere al software di keypass. Qualcosa del genere mywifesnameisangelaandshehasanicebuttè invunlerabile agli attacchi del dizionario, è molto forte e molto semplice da ricordare, ma impossibile da indovinare. E viene fornito con il bonus se punti brownie se hai mai bisogno di dare la password a tua moglie.

— Mark Henderson

7

Scusa, Mark, ma è sbagliato. La passphrase che hai dato ha 37 caratteri e quindi circa 44 bit di entropia, che è più debole di 7 caratteri stampabili casuali ed è altamente attaccabile. Leggi l'articolo di Wikipedia sull'opera di Claude Shannon per i dettagli, ma il risultato è che l'inglese scritto è altamente prevedibile - ad esempio, dopo "mywifesname", la parola "is" è quasi garantita. Per password complesse che coinvolgono parole, quattro parole casuali messe insieme da un dizionario ti daranno circa 10 ** 23 possibilità, che sono circa 77 bit di entropia; ancora non eccezionale, ma non male.

— MadHatter il

7

Quando si accede con una password, si trasmette la password al server. Ciò significa che l'operatore del server può modificare l'SSHD per ottenere l'accesso alla password. Con l'autenticazione con chiave pubblica, non possono ottenere la chiave privata poiché solo la chiave pubblica va al server.

— Ramon
fonte

2

Ciò è particolarmente rilevante quando ci si connette al server sbagliato a causa di un errore di battitura. Ad esempio, ad un certo punto nel tempo, .cg era un carattere jolly che puntava a una singola macchina con ssh abilitato. Ogni volta che dovresti digitare in modo errato .cg per .ch, finiresti per collegarti a quella casella e perdere la tua password ...

— b0fh

@ b0fh davvero. Per quanto ne so, questa è l'unica vera vulnerabilità introdotta usando le password con ssh. Se qualcuno possiede già il server a cui ti stai connettendo o può falsificare gli indirizzi IP a cui ti stai connettendo (MITM), hai già perso.

— Piani cottura

6

i tasti ssh impediscono agli attacchi man in the middle basati sulla tua password.

quando si tenta di accedere con una chiave, il server costruirà una sfida basata sulla chiave pubblica e la invierà al client. che lo decifrerà e costruirà una risposta appropriata da inviare.

La tua chiave privata non viene mai inviata al server e chiunque sia in ascolto non può fare altro che intercettare quella singola sessione.

con una password avrebbero le tue credenziali.

La mia soluzione è quella di avere una chiave ssh portatile in formati adeguati su una partizione crittografata su una chiave USB. questo mi permette di:
ritrarre facilmente quella chiave in caso di smarrimento.
limitare i server a cui mi consente di accedere
e comunque trasportarlo in giro

sebbene l'installazione del software di mount sia un problema (TrueCrypt)

— Tacticus
fonte

1

Questo è sbagliato. Non appena conosci la chiave pubblica del server (cosa che fai se l'hai aggiunta alla cache e non hai ricevuto MITM sulla prima connessione) sei immune agli attacchi MITM. L'autenticazione basata su chiave / password non ha nulla a che fare con essa. La password non viene mai inviata in chiaro via cavo, una connessione sicura all'autenticazione a livello di macchina (qual è la tua / mia chiave pubblica) viene sempre impostata prima dell'autenticazione a livello di utente (qual è la tua password / dimostrami che questa chiave pubblica è tua) .

— Thomas,

3

Thomas, in realtà molte persone ignorano l'avvertimento di un cambio di impronte digitali. Pubkey auth garantisce la protezione MITM anche se la chiave privata del server viene in qualche modo compromessa o un tipo umano "sì" distrattamente: l'aggressore deve scegliere tra la possibilità di vedere il traffico e l'invio di una chiave pubblica che non accederà, che è un vincere.

— Score_Under

5

E al risponditore: non è necessario utilizzare TrueCrypt, le chiavi private di openssh sono fornite con la propria crittografia opzionale basata su password.

— Score_Under

5

È un compromesso, come dice @MartinVejmelka.

Il motivo per cui usi l'autenticazione basata su chiave è che la chiave è molto al di sopra della forza bruta attuale o quasi futura che devi provenire dal tuo PC o avere la chiave su una chiavetta USB o simile.

Una password presenta i seguenti problemi:

Se è corto, può essere forzato brutalmente
Se è lungo, viene facilmente dimenticato
Potrebbe essere praticato surf sulla spalla

Una chiave è più lunga di ordini di grandezza e non viene visualizzata in nessun punto, quindi evita questi tre problemi.

— Rory Alsop
fonte

ma l'uso di un file chiave aggiunge il problema di perdere la pen drive o qualsiasi altra memoria si stia utilizzando.

— João Portela,

1

a quel punto la chiave persa può essere rimossa e una nuova chiave aggiunta. Con le password (in particolare le password condivise) questo può farmi un MAJOR dolore e comporta un sacco di gemiti.

— SplinterReality,

Una delle mie password (di recente in pensione): 08Forging2?seminal*^Rajas-(Posed/|. Viene generato casualmente ma non ho problemi a ricordarlo. E in bocca al lupo alla spalla o alla forza bruta.

— Finnw,

1

@finnw Pinza batteria a cavallo corretta :-) security.stackexchange.com/q/6095/485

— Rory Alsop

2

Aspetti positivi citati già qui.

Quello che considero il rischio maggiore, dato che ti sei preso cura delle basi con una password complessa, è che molti computer hanno installato keylogger senza che l'utente se ne accorga. Ci sono persino persone che creano interi siti di utilità utili che contengono trojan, quindi può accadere al meglio di noi. Un keylogger, ad esempio, invierebbe per e-mail i dettagli di accesso a un hacker che potrebbe facilmente accedere al server.

Di recente sono stato avvisato da Norton del download del programma di installazione di Zombee Mod (non del vaso, del programma di installazione) per l'aggiunta del volo al vaso di Minecraft. Ho guardato i dettagli e Norton ha elencato molte utility su questo sito che è stato contrassegnato come contenente un trojan. Non so se sia corretto o meno, ma era piuttosto specifico con i nomi dei file. È anche noto che i trojan vengono messi in (alcuni) warez prima di essere distribuiti.

— Tedd Hansen
fonte

2

Un potenziale vantaggio di SSH rispetto alle password è che se non si specifica una passphrase SSH, non è necessario digitare nuovamente una password ... il computer è intrinsecamente attendibile sul server perché ha la chiave. Detto questo, di solito uso sempre una passphrase SSH, quindi escludo che ne tragga beneficio.

Trovo la migliore risposta al perché le guide per l'utente spesso raccomandano SSH tramite l'autenticazione tramite password proviene dal manuale di Ubuntu per SSHOpenSSHKeys. Quoto,

Se non pensi che sia importante, prova a registrare tutti i tentativi di accesso dannoso che ricevi per la settimana successiva. Il mio computer - un PC desktop perfettamente normale - ha avuto oltre 4.000 tentativi di indovinare la mia password e quasi 2.500 tentativi di intrusione solo nell'ultima settimana. Quante migliaia di ipotesi casuali pensi che ci vorrà prima che un utente malintenzionato si imbatta nella tua password?

Essenzialmente se hai una password solida e di alta lunghezza con punteggiatura, lettere maiuscole e minuscole e numeri ... probabilmente starai bene con l'autenticazione della password. Inoltre, se prevedi di monitorare i tuoi registri e non esegui comunque operazioni "super sicure" attraverso la rete ... ovvero utilizzandolo per un server di casa. Quindi, sicuramente, una password funziona bene.

— MikeMurko
fonte

1

Il metodo di autenticazione Passwd è davvero insicuro (imho). Con questo meccanismo la password verrà trasmessa al server sshd (come ha già detto @ramon). Ciò significa che alcune persone potrebbero modificare il server sshd per recuperare la password. Con un attacco Man-In-The-Middle questo è molto facile da realizzare all'interno di una rete locale.

Puoi semplicemente patchare il server sshd installando questa patch ( https://github.com/jtesta/ssh-mitm ). Utilizzare arpspoofe iptablesper mettere il server con patch tra il client e il server SSH autentico.

Disabilita l'autenticazione password: apri il file di configurazione /etc/ssh/ssh_confige aggiungi la riga PasswordAuthentication no.

— Pioz
fonte

Il client SSH non controlla il server per l'impronta digitale RSA? Dopo aver eseguito lo spsh su questo particolare server almeno una volta, la sua impronta digitale verrà ricordata, quindi nel caso di possibili attacchi MITM SSH accenderebbe un avviso, no?

— Settagramma

1

Si. Viene visualizzato l'avviso ma poiché il 99% delle volte è causato dalla reinstallazione del sistema operativo, dalla configurazione modificata ecc, la maggior parte degli utenti ignorerà l'avviso e proseguirà.

— Pioz,

@Septagram Molti provider di account di shell non hanno l'abitudine di pubblicare l'impronta digitale chiave del server corrente per i nuovi abbonati, per la migrazione degli account utente su nuovi server, ecc.

— Damian Yerrick,

-2

È possibile ignorare l' -o StrictHostKeyChecking=noopzione con. Questo è molto utile quando si usa ssh in uno script di shell.

ssh -o StrictHostKeyChecking=no -o ConnectTimeout=10 -o PasswordAuthentication=no -o ConnectionAttempts=5 xxUser@xxxHost

— arganzheng
fonte