È sicuro disabilitare la chiave host SSH controllando se viene utilizzata l'autenticazione basata su chiave?

Naviga le tue risposte
19

Ho alcuni compiti che vanno così:

  1. Crea nuove istanze EC2 (Amazon Web Services)
  2. Chiedi loro di eseguire un'attività
  3. Uccidili

Il problema è che sono (apparentemente) assegnati in modo casuale a un indirizzo IP, e per caso una nuova macchina ha riutilizzato un indirizzo che era stato precedentemente utilizzato.

Questo ovviamente ha portato al seguente errore e il mio script non è riuscito: 

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is 
Please contact your system administrator.
Add correct host key in /home/ec2-user/.ssh/known_hosts to get rid of this message.
Offending RSA key in /home/ec2-user/.ssh/known_hosts:595
RSA host key for 127.0.0.1 has changed and you have requested strict checking.
Host key verification failed.

Sto usando una coppia di chiavi quando mi collego a queste macchine, piuttosto che usare l'autenticazione della password. Ciò impedirebbe un attacco man-in-the-middle, poiché un utente malintenzionato non avrebbe la stessa coppia di chiavi?

Sono sicuro di disabilitare il controllo della chiave host SSH?

    
posta Dean 03.08.2013 - 01:18
fonte

2 risposte

14

Risposta breve: Sì e no.

Prima di tutto, facciamo le cose per bene. In ogni caso, come funziona l'autenticazione basata su chiavi in SSH? Una volta che la connessione SSH raggiunge la fase di autenticazione, il client firma una serie di dati (questo include l'identificativo di sessione) con la sua chiave privata, quindi invia la firma al server per verificarlo.

Passaggio per la verifica della firma - > Autenticazione riuscita.

In che modo un attacco MiTM in questo caso? L'aggressore si trova tra te e il server. Per un attacco di successo ha bisogno di te per iniziare una sessione con lui, e ha bisogno di avviare una sessione con il server. Qualunque cosa tu invii al server, in realtà andrà da lui e lui ha la possibilità di modificarlo e inviarlo al server, e qualunque cosa il server ti mandi andrà effettivamente dall'attaccante e l'attaccante può modificarlo e inviarlo a te .

Hai notato qualcosa di interessante? Ci sono due sessioni qui (tienilo a mente). Ogni sessione avrà il proprio identificativo di sessione perché la generazione dell'identificatore di sessione non è determinata dal server o dal solo client. In altre parole, la firma che si utilizza per l'autenticazione per l'autore dell'attacco sarà diversa dalla firma che l'utente malintenzionato deve utilizzare per autenticare il server reale.

L'utente malintenzionato non ha la chiave privata del client, il che significa che non sarà in grado di fornire una firma accettata dal server reale. Ecco perché questo tipo di MiTM completo non sarà possibile.

Quindièsicurodisabilitarelaverificadellachiavedell'host/improntedigitali,giusto?Nonesattamente.Èverochepoichél'autoredell'attaccononèingradodiautenticarsisulserver,nonsaràingradodieseguirecomandidannosisudiesso.MA

Ricordiquandotihoparlatodelleduesessioni?L'attaccantenonsaràingradodistabilireunasessioneconilserverreale,mapuòfacilmentefartistabilireunasessioneconlui.L'attaccanteaccetteràsemplicementequalsiasifirmatuglidaietiindurràapensarecheoraseiconnessoalserverreale.Gliinvieraiicomandi(epossibilmentealcunepasswordspecificheperilprocesso)eluirisponderàallegramenteconqualsiasicosatirendafelice.

Certo,nonc'èalcunpericolorealeperilserverquipoichétalicomandinonraggiungonorealmenteilserver.Èsolochenonsisacosamanderaieffettivamenteilserver(oral'attaccante).Potrestiinviarechiavi,password(pensachequandomodifichilapasswordilservertichiederàlapasswordcorrente)ealtreinformazionisensibili.

Lalineadifondoè:seseidispostoadaccettareilrischiodiconnettersiaunserverfalsochesapràcosastaiinviandoalserverreale,quindidisabilitailcontrollodellachiave/improntadigitaledell'host.Altrimenti,tieniloabilitato.

References:

risposta data 03.08.2013 - 13:59
fonte
3

Non sarebbe sicuro se l'inoltro dell'agente SSH è abilitato nella configurazione per il server in questione.

Se utilizzi un agente SSH per gestire l'autenticazione basata su chiave e utilizzi ssh -A o se hai qualcosa di simile in ~/.ssh/config : 

Host example.com
    ForwardAgent yes

o se hai attivato ForwardAgent a livello globale, non è sicuro saltare o ignorare i controlli delle chiavi host.

La risposta accettata è eccellente ma omette questo avvertimento molto importante.

Con l'inoltro dell'agent abilitato e supponendo che il tuo agente abbia la chiave per il server MITMed, l'utente malintenzionato può permetterti di connettersi ad esso come descritto nella risposta accettata, quindi creare una nuova connessione al server reale usando il chiave dall'agente inoltrato. La maggior parte degli agenti (tutti?) Lo permetterà silenziosamente. E il risultato sarebbe che ora hai una connessione MITMed al server reale.

In qualche modo, questo è analogo all'attacco MITM per l'autenticazione della password. Nello scenario di autenticazione della password, il MITM ruba la tua password e la usa per autenticare il server in modo che tu non ne sia più saggio. Nello scenario di autenticazione della chiave pubblica (con l'inoltro dell'agente), l'utente malintenzionato si avvale del proprio agente per l'autenticazione. Quindi, sebbene l'utente malintenzionato non acquisisca il possesso della chiave, l'utente malintenzionato potrebbe utilizzare la chiave tramite l'agente per l'autenticazione come al server e anche per impersonare l'utente su altri host che accettano la chiave (ma solo per la durata della sessione ).

Questo scenario e lo scenario SSH agent hijacking nel caso non MITM sono i due motivi per essere MOLTO attenti su quali host inoltrare il tuo agente a. Pensa a tutto ciò che un utente malintenzionato potrebbe fare con l'accesso alle chiavi che il tuo agente ha caricato. Ad esempio, se la stazione di lavoro è configurata per accettare una delle chiavi, l'utente malintenzionato potrebbe eseguire di nuovo ssh sulla workstation e recuperare la chiave privata SSH. E se la chiave privata ha una passphrase, l'utente malintenzionato potrebbe installare un keylogger e attendere pazientemente fino alla successiva decodifica.

    
risposta data 12.01.2017 - 20:20
fonte

Leggi altre domande sui tag

Quanto è cattivo Spectre? Informazioni sulla privacy: l'account Facebook viene visualizzato con una ricerca del numero di telefono, nonostante non venga mai aggiunto: cosa devo fare? [chiuso]