Come posso impedire che le chiavi caricate in ssh-agent vengano inviate a un server particolare (non sicuro)?

Question

Come posso impedire che le chiavi caricate in ssh-agent vengano inviate a un server particolare (non sicuro)?

#1 da (8 voti)

1

Un particolare server con cui ho bisogno di interagire ha un sshd antico o azzoppato, e supporta solo gli algoritmi SHA1 per lo scambio di chiavi. Dalle informazioni contenute nei documenti di Snowden, mi dispiace che le chiavi scambiate con server con algoritmi di scambio di chiavi deboli possano essere intercettate.

Conservo un'identità separata che utilizzo solo con questo server e ho una voce ~/.ssh/config specifica per utilizzare quell'identità durante la connessione; e il mio ssh_config a livello di macchina non consente gli algoritmi di scambio di chiavi non sicuri.

Tuttavia, se ho aggiunto la mia chiave normale a ssh-agent , sembra che la mia chiave si spera, più sicura, venga comunque inviata tramite lo scambio di chiavi potenzialmente insicuro.

C'è un modo per proteggere ulteriormente la mia configurazione, in modo che possa impedire che una chiave che tengo sicura e privata venga trasmessa con un algoritmo di scambio di chiavi che perde?

Se no, dovrebbe esserci ? Sembra che una parte del contratto dell'agente sia "tutti questi algoritmi di scambio di chiavi sono assolutamente sicuri al 100%, quindi è ok di inviare qualsiasi chiave". Poiché gli algoritmi di scambio delle chiavi sono non tutti sicuri, questo è (è?) Un problema.

Mentre gli algoritmi di scambio delle chiavi possono essere bloccati a livello di macchina, questo non sempre funziona nella pratica, ed è piuttosto facile sovrascriverlo accidentalmente / intenzionalmente nella configurazione per utente. C'è (o ancora, dovrebbe esserci) un modo per configurare "identità XYZ può solo essere usato con KexAlgorithms / Ciphers / MACs?"

Dettagli Gori:

Ho un'identità rsa id_insecure che voglio usare con il server non sicuro e un'identità ed25519 id_secure che uso per impostazione predefinita.

Per evitare alcuni algoritmi di scambio di chiavi potenzialmente deboli, il mio /etc/ssh_config contiene:

Host *
    KexAlgorithms [email protected],diffie-hellman-group-exchange-sha256

Per consentire l'accesso al server non sicuro, poiché non possono concordare un algoritmo di scambio delle chiavi con l'impostazione precedente, my ~/.ssh/config contiene:

Host insecure_server
    IdentityFile path_to/id_insecure
    KexAlgorithms diffie-helmann-group14-sha1,and-some-other-icky-sha1-algorithms

Tuttavia, se carico id_secure nel mio agente SSH e ssh -vvv insecure_server , l'output conterrà

debug1: Offering ED25519 public key: path_to/id_secure
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: ...

La mia comprensione è che ho appena inviato la mia identità id_secure usando l'algoritmo di scambio di chiavi diffie-helmann-group14-sha1, che non è sicuro come una volta pensato. Se mi sbaglio su ciò che viene passato in giro ... troverei anche quella informazione preziosa.

ssh

posta danwyand 09.01.2015 - 20:35

fonte

1 risposta

Leggi altre domande sui tag ssh

Scrittura di keylogger e virus in python [chiuso] Potrebbe John Oliver essere (inavvertitamente?) lanciato attacchi DOS?

score 8 · Accepted Answer

Hai diversi malintesi qui.

Innanzitutto, l'intero punto di una coppia di chiavi pubblica / privata è che non si invia la chiave privata al server. L'unica cosa per cui la tua chiave è usata è la firma dei messaggi; il server non ottiene la tua chiave privata in qualsiasi momento durante il protocollo SSH. Anche se utilizzi l'inoltro dell'agent (che ti consente di accedere ad altri server dal primo utilizzando la tua chiave), il server non ottiene la tua chiave privata: passa semplicemente le cose a ssh-agent su tuo computer, che li firma e invia la firma al primo server per l'invio in linea.

In secondo luogo, "scambio di chiavi" in questo contesto non significa "passare le chiavi", significa "stabilire un segreto condiviso". Il modo in cui Diffie-Hellman funziona è che il client e il server elaborano una nuova nuova chiave, che è completamente estranea a qualsiasi chiave che potrebbero aver avuto prima. Le chiavi a lungo termine (vale a dire i keypair che sono memorizzati nei file) vengono utilizzate solo per firmare gli elementi dello scambio di chiavi, in modo che tu sappia che stai parlando al server con cui pensi di parlare.

In terzo luogo, lo scambio di chiavi in SSH non ha nulla a che fare con le chiavi client ( id_rsa e simili). Il server si autentica da solo durante lo scambio delle chiavi utilizzando la chiave host, ma l'autenticazione del client non avviene durante lo scambio delle chiavi. Viene utilizzata tutta una chiave client per firmare una particolare stringa dopo lo scambio di chiavi (e dopo aver inviato il nome utente a cui si desidera accedere), per dimostrare che è possibile firmare le cose con una chiave privata corrispondente a una chiave pubblica autorizzata per quell'utente. Gli algoritmi di scambio delle chiavi non hanno nulla a che fare con le chiavi client.

Quindi, lo scambio di chiavi deboli non pone alcun problema per la sicurezza della chiave privata. Quella sicurezza non si basa su un strong scambio di chiavi. L'unico attacco che puoi fare è sfruttare l'inoltro dell'agente, ma ciò potrebbe funzionare solo se a) l'hai abilitato in un primo momento eb) sei ancora connesso (disconnessione = non più inoltro agente).

In quarto luogo, in realtà non sono a conoscenza di un problema con l'utilizzo di SHA-1 per l'hash dello scambio. SHA-1 è debole per attacchi di collisione , il che significa che è più facile di quanto dovrebbe essere creare due hash allo stesso valore. Ma per eseguire con successo la connessione MITM, è necessario un secondo attacco preimage , che significa creare una collisione con qualcosa che non si controlla. In un attacco di collisione controlli entrambe le metà della collisione, che è un problema se stai firmando qualcosa e l'attaccante può controllare ciò che stai firmando, nel qual caso l'attaccante potrebbe creare una coppia in collisione, farti firmare una cosa e usalo come firma dell'altra cosa. Mentre in genere è meglio allontanarsi da esso, definirlo insicuro per i casi che richiedono solo una resistenza al secondo preimage è un po 'troppo lungo.