La tua password SSH viene rivelata quando tenti di connetterti al server sbagliato?

192

Quando si tenta di connettersi accidentalmente al server errato con le credenziali della password, è possibile che l'amministratore legga e registri la password utilizzata?

ssh password

— vfclists
fonte

11

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

— jamesdlin,

41

In un client SSH, per prima cosa autentichi il server e così dici "Confido di poter dire la mia password a questo server". La prossima volta presta maggiore attenzione al messaggio che hai visto per primo: "L'autenticità di X non può essere stabilita. L'impronta digitale della chiave RSA è Y Sei sicuro Z? (Sì / no)" Questa fastidiosa domanda non verrebbe fatta se supponessi per rispondere automaticamente sì ogni volta.

— Kubanczyk,

6

È possibile impostare PasswordAuthentication nodi default in OpenSSH e abilitarlo (se / quando necessario) solo per server fidati. In combinazione con un rigoroso controllo della chiave host, questo dovrebbe proteggerti principalmente dall'esporre la tua password, ovviamente a un costo conveniente.

— Hobbs,

6

@kubanczyk, se si desidera SSH su "internal-www.my-company.com" ma si è digitato accidentalmente "ssh www.my-company.com", tale prompt non ti proteggerà - è probabile che entrambi i server lo siano nel tuo elenco di fiducia, è solo che uno di essi è gestito da te e l'altro da una terza parte.

— Segna il

@hobbs, ChallengeResponseAuthentication noanche io credo

— ilkkachu il

215

In poche parole: sì

Più dettaglio...

Se ti connetti alla mia macchina, non sai se sto utilizzando un sshserver normale o che è stato modificato per scrivere la password che viene passata.

Inoltre, non avrei necessariamente bisogno di modificare sshd, ma potrei scrivere un modulo PAM (ad es. Usando pam_script), al quale verrà passata la password.

Quindi sì. MAI inviare la password a un server non attendibile. Il proprietario della macchina avrebbe potuto facilmente configurarlo per registrare tutte le password tentate.

(In realtà questo non è raro nel mondo dell'infosec; configurare un server honeypot per registrare le password tentate)

— Stephen Harris
fonte

13

Corretta. Per impostazione predefinita, lo standard sshdnon non registrare le password. (Se inserisci la password come nome di accesso, verrà registrata, ma questo è un altro problema). Lo standard sshdè uno strumento di sicurezza, quindi non registrerà le credenziali in questo modo :-)

— Stephen Harris,

116

Ancora un altro motivo per usare coppie di chiavi pubbliche / private ...

— gerrit,

3

Mi chiedo da tempo il mio utilizzo delle password e recentemente mi sono reso conto che tentare di accedere a server sbagliati sarebbe un buon modo per rivelare la mia password a un amministratore di server malintenzionato.

— vfclists,

10

Anche @vfclists accedendo al server sbagliato è esattamente il motivo per cui il tuo client sshd memorizza l'impronta digitale per ciascun server. Quando ti connetti per la prima volta, accetti quell'impronta digitale, quindi in seguito se non corrisponde, ricevi un avvertimento gigante che dovresti ascoltare.

— hometoast,

44

Consiglio migliore: non usare mai la password auth per ssh. Il protocollo ha autenticazione pubkey per ottime ragioni; usalo!

— R ..

52

Sì.

La password viene inviata dopo aver stabilito la connessione crittografata, ma il server remoto ottiene la password in testo normale.

Se ti interessa, la soluzione migliore e più semplice è usare le chiavi SSH.

Se si dispone di macchine che non possono accettare chiavi, una soluzione sarebbe quella di creare uno strumento che memorizza le password in modo sicuro e che quindi utilizza sshpasssempre per inviare la password corretta a seconda del server a cui ci si sta connettendo.

Ora, il motivo per cui la password viene inviata in chiaro, è che lascia tutte le decisioni di gestione e archiviazione sul lato remoto e il client può essere totalmente stupido. Esistono un paio di diversi formati di hashing (archiviazione) delle password utilizzati nei sistemi Linux e BSD negli ultimi dieci anni circa ( crypt (3) ), nessuno dei quali richiede supporto dal client.

Anche se ciò è in parte dovuto anche alla storia (cioè è sempre stato così). Esistono protocolli di autenticazione challenge-response che potrebbero essere utilizzati anche con le password. Ad esempio SRP , che fornisce alle parti un segreto condiviso durante l'autenticazione. È stato implementato per alcuni server SSH, ma la patch per OpenSSH è per una versione (molto) vecchia.

— ilkkachu
fonte

1

Il problema con i protocolli challenge-response per l'autenticazione password è che alcuni di essi richiedono che il server memorizzi la password in testo semplice. Se il protocollo challenge-response consente al server di memorizzare una password con hash, molto probabilmente richiede un algoritmo di hashing molto specifico.

— Kasperd,

8

Le password vengono generalmente inviate in "testo semplice" (cioè non in realtà in chiaro, ma solo con la protezione che il SSH sottostante | TLS | qualunque sia la connessione). Se un sistema richiedesse che le password vengano hash lato client e che sia inviato l'hash, i server non avrebbero modo di derivare la password effettiva e concederebbero invece l'accesso a chiunque potesse fornire l'hash della password , rendendo tale hash password equivalente .

— Blacklight Shining

1

@BlacklightShining Esistono prove di password a conoscenza zero, ma non vengono utilizzate in SSH perché non c'è modo di utilizzare il database di password standard per loro e nessun punto reale per usarle piuttosto che l'autenticazione basata su chiave.

— Casuale 832,

dove posso vedere quelle password usate per autenticare? Non sono in /var/log/auth.log, dove allora?

— アレックス

OpenSSH non registrerà le password, non riuscite o altrimenti. (Non ho molta familiarità con altri server SSH.) In quasi tutte le installazioni legittime, qualsiasi valore che questo potrebbe fornire sarebbe superato dal rischio inerente alla registrazione intenzionale di password, alcune delle quali potrebbero essere state fornite da utenti legittimi che hanno fatto un errore di battitura o provato una password errata ma giusta per qualcos'altro — in chiaro. Se hai una buona ragione per farlo, comunque, sarebbe facile patchare OpenSSH.

— musicinmybrain,

10

Per basarsi sulla risposta di Stephen Harris, ecco una vista in tempo reale che ho creato che mostra ciò che uno script di autenticazione PAM modificato sarebbe in grado di catturare quando si connetteva a un box su ssh (un tipo di honeypot). Uso una versione modificata della libreria PAM lib-storepw.

https://livesshattack.net

https://livesshattack.net/about

— Willie S.
fonte

4

Le risposte che sono principalmente collegamenti vengono disapprovate nel caso in cui il collegamento non sia disponibile (sembra che tu mantenga questo sito personalmente, ma comunque). Dovresti descrivere un po 'come hai gestito questo con il tuo script di autenticazione per i lettori.

— Centimane,

non funziona più, ho inviato una stringa enorme come password, penso che potrebbe averlo rotto, scusa: - /

— scottydelta

@scottydelta Anche se non l'ho esaminato, potrebbe esserci un limite di buffer sulla dimensione della password che il modulo PAM o il demone SSH può accettare in un tentativo di autenticazione. Il sito funziona ancora come volevo, sebbene gestirà fino al limite di buffer accettato dal modulo sshd o PAM se questo è davvero il caso.

— Willie S.,

Non interessante è la fonte per il tuo lib-storepw modificato disponibile per altri?

— Tim Fletcher,

2

SSH è un protocollo che richiede fiducia reciproca. Questo è il motivo per cui il client OpenSSH mantiene un file known_hosts, per implementare la sua fiducia al primo utilizzo.

Quando si tenta di accedere a un server SSH, indipendentemente da chi ha fornito il software o da quali dati è configurato per la registrazione, si partecipa a una procedura di autenticazione. Quando si utilizza l'autenticazione password, si sta trasmettendo la password a quel server. Questo è uno dei motivi per cui si consiglia la crittografia asimmetrica (chiave pubblica, certificati): la crittografia a chiave pubblica riduce notevolmente il rischio di divulgare le proprie credenziali. (Anche se questo potrebbe non proteggerti da un attacco MitM se usi l'inoltro di ssh-agent o uno schema simile.)

— jvoorhis
fonte

SSH non richiede fiducia reciproca, o almeno non fiducia simmetrica. È importante essere precisi: known_hosts riguarda l'autenticità, non la fiducia. Come fai notare, posizionare una chiave pubblica su un host meno affidabile è sicuro. In effetti, usare una password per accedere è anche "sicuro", supponendo che non riutilizzi quella password. (Ovviamente è sicuro quanto il livello di affidabilità del server.) Anche gli accessi ssh basati su host dipendono dall'affidabilità asimmetrica.

— Markhahn,