SSH publickey leak

3

Quando mi collego a un server SSH, so che sto inviando il mio publickey per essere confrontato con il file authorized_keys.

La domanda è: quanto dalla chiave pubblica viene inviato via cavo? Include utente e nome host del proprietario della chiave?

Come posso registrare questi dati?

    
posta sektor 04.08.2016 - 19:28
fonte

2 risposte

3

Ok, sono stato spinto a scrivere una risposta per chiarire le cose. Non che l'altro sia completamente sbagliato, ma non mostra l'intero quadro di ciò che sta accadendo nel protocollo SSH.

L'autenticazione su ssh server funziona in due passaggi. Il primo è la convalida se la tua chiave pubblica è nel file authorized_keys , la seconda verifica se la firma fornita dalla parte privata appropriata è valida. Nel registro di debug del server, puoi vedere:

sshd[9951]: debug1: test whether pkalg/pkblob are acceptable
sshd[9950]: debug1: matching key found: file /home/user/authorized_keys, line 1
sshd[9950]: Found matching RSA key: 8b:3c:20:c5:03:c4:c0:03:74:83:0a:8f:2d:d8:48:a2
sshd[9951]: Postponed publickey for vagrant from 10.0.2.2 port 54361 ssh2

riferito al primo passo ( test whether pkalg/pkblob are acceptable ). E dopo uno

sshd[9950]: debug1: matching key found: file /home/user/authorized_keys, line 1
sshd[9950]: Found matching RSA key: 8b:3c:20:c5:03:c4:c0:03:74:83:0a:8f:2d:d8:48:a2
sshd[9950]: Accepted publickey for user from 10.0.2.2 port 54361 ssh2
sshd[9950]: debug3: mm_answer_keyverify: key 0x7f54ce6ac570 signature verified

sta controllando la vera firma fatta dalla parte privata della chiave.

Leggermente parafrasato la mia risposta da diverse domande su sec.SE

Ma nota che il primo passo non è obbligatorio. Se specifichi solo chiave privata o imposti l'utilizzo di una chiave specifica, il primo passaggio viene saltato e in questo caso, la domanda precedente è corretta.

Tutta la comunicazione di cui sopra (autenticazione) è già crittografata. Va sul filo, ma non è possibile intercettarlo in mezzo. Il server deve vederlo, se offri questa chiave.

Se sei preoccupato per la tua chiave pubblica, nota che ad esempio Gitbub espone le chiavi pubbliche sull'URL https://github.com/<username>.keys . Non è un grosso problema come dice un nome (pubblico). Sulla base di questo, c'è servizio , che ti identifica anche al di fuori di github, ma devi comunque fai il primo passo (connettiti al server non affidabile, che di solito è una pessima idea).

    
risposta data 05.08.2016 - 21:16
fonte
4

Quando ti connetti al server SSH, non stai inviando la tua chiave pubblica per il confronto. Piuttosto, ciò che sta succedendo è lo scambio di dati client / server crittografato con la chiave pubblica e quindi la convalida che il client ha effettivamente accesso alla chiave privata corrispondente.

In SSHv1, il server crittografa un messaggio con la chiave pubblica del client e il client restituisce un checksum del messaggio.

In SSHv2, il client crittografa un messaggio con la chiave privata del client e invia una firma del messaggio. Il server quindi ricrea il messaggio e controlla attraverso authorized_keys per convalidare la firma.

In sostanza, ciò che accade è il test del server per vedere se è possibile decodificare e quindi rispondere alle informazioni crittografate con la chiave pubblica.

Nessuno di questi viene inviato "over the wire" non crittografato, poiché viene avviata una connessione SSH crittografata prima dello scambio di queste frasi.

Per visualizzare ulteriori dettagli, puoi utilizzare WireShark, Snort, Suricata o un altro sniffer di pacchetti per ispezionare il traffico non elaborato.

    
risposta data 04.08.2016 - 19:57
fonte

Leggi altre domande sui tag