L'autenticazione della password SSH fornisce al server la password?

Cosa succede se abbiamo inviato l'hash?

Se l'hash era il parametro di autenticazione e non la password, l'hash sarebbe il parametro di autenticazione.

Per spiegare questa tautologia in modo più approfondito: viene cancellata una password in modo che se l'archivio dati delle password è compromesso, non si ha una credenziale di autenticazione funzionale. Per questo motivo, è la password che viene inviata al server in cui il server esegue il lavoro per calcolare l'hash. L'invio dell'hash di una password sarebbe esattamente lo stesso di un generatore di password senza hashing.

Le tue password sono state compromesse se qualcuno ha il controllo del server?

Possono ancora rubare le password, forzando bruto l'archivio di autenticazione per generare la password non elaborata, o in modo più efficiente alterando il codice del daemon del server per registrare i tentativi di password.

Could someone clarify if this is correct?

Sì , è corretto che la password sia nota al server in testo normale. RFC 4252, sezione 8 specifica "Password Authentication" per SSH e scrive (liberamente citato):

Si noti che [...] la password in chiaro viene trasmessa nel pacchetto [...].

Volevo anche fornire una risposta, non sulla domanda in sé, ma su

Can you design a protocol which doesn't send the server the password or values equal to the password?

La risposta è Sì .

Dovresti assicurarti che il tuo protocollo faccia quanto segue:

1. (più parte dell'implementazione) L'utente deve avere alcuni mezzi per confermare che non stanno dicendo la password al server. Il protocollo più intelligente non ha senso se il server può bypassarlo visualizzando un testo che può ottenere il contenuto. Questo è un problema se l'applicazione è solo un terminale remoto, e l'autenticazione sta già accadendo durante questa "modalità terminale remoto", o se il server può "falsificare" la connessione senza inserire una password, e quindi visualizzarne la sua. Un altro esempio potrebbe essere un sito Web con un modulo html. L'autenticità della finestra di dialogo "popup pop up" è stata progettata pensando a questo problema.
2. Dovresti utilizzare un protocollo di risposta alle sfide come SCRAM o SRP . Se la tua registrazione della password è progettata in modo da non fornire una chiave al server (o ti fidi del server al momento della registrazione, come nell'esempio), entrambi non forniscono valori al server che possono utilizzare per accedere ad altri server con la stessa password. Per SCRAM, i tuoi sali devono essere unici per server, SRP ti esonera da tale dovere.
3. Devi utilizzare la crittografia insieme a Associazione canali tra il tuo livello di crittografia e il tuo livello di risposta alle sfide. Questo renderà i server infetti non in grado di giocare "man in the middle" a un server di destinazione per la parte di autenticazione della connessione, quindi fare il loro malvagio business dopo di esso. SRP supporta questo per la sua natura come un protocollo di scambio chiave e lo SCRAM RFC ufficiale ha anche il supporto per il binding del canale.

Tuttavia, questa è una discussione prevalentemente teorica. Dovresti usare le chiavi ssh ovunque possibile , perché offrono una protezione brute-force molto migliore.

Could someone clarify if this is correct?

Questo è un problema relativo. Voglio dire, dipende dalla natura del controllo che la persona malvagia ha sul server. Se è abbastanza esperto per modificare / trap daemon SSH (situato sul lato server), potrebbe ottenere la tua password. Ma questo è meno pratico in realtà perché ci sono i modi più semplici per ottenere la password per un hacker ostinato da brute-forzare la tua password .

Tuttavia, il modo più sicuro per connettersi al server utilizzando SSH è utilizzare Usa coppie di chiavi pubbliche / private per l'autenticazione anziché le password perché brute-forzarli è semplicemente impossibile .