Probabilmente si confonde un po 'cosa sta accadendo tra client e server quando comunicano su un canale criptato ( ssh o tls non importa più di tanto - il modello comunque implica due tipi di cifrari).
In sostanza, ci sono due tipi di costrutti crittografici che hanno usato: cifrari simmetrici e asimmetrici (ometterei di descrivere altri dettagli nitty-grintosi che implicano l'integrità di un dato, ecc.)
Ciò che generalmente accade, è il seguente (esempio ssh con verifica chiave e accesso password disabilitato):
Crittografia asimmetrica
-
Il client ha una chiave privata (di solito un file chiamato id_rsa ) e il server ha una chiave pubblica corrispondente (situata in un file known_hosts ).
-
Quando il client vuole ssh in un particolare host, stabilisce una connessione TCP inviando il proprio nome utente. Il server corrisponde a una chiave pubblica corrispondente da known_hosts a questo particolare nome utente e invia una sorta di richiesta al cliente.
-
Questa sfida è risolvibile solo con una chiave privata corrispondente che il client dovrebbe avere sul proprio computer. Il client risolve la sfida e invia i risultati al server che verifica la soluzione e consente all'utente di accedere (o rifiuta il client se la soluzione non è corretta - il che significa che la chiave privata è errata).
Dopo questo punto, se all'utente è stato concesso un accesso, crypto simmetrico inizia a riprodurre il suo ruolo.
Crypto simmetrico
-
L'utente è stato autenticato da un server e la chiave di sessione è generata sul lato server che quindi viene inviata a un client crittografato con la sua chiave pubblica (sempre da known_hosts ).
-
Questa chiave di sessione è una chiave segreta di un cifrario simmetrico molto più veloce della crittografia asimmetrica (cioè AES). Questa chiave viene quindi utilizzata per crittografare tutto il traffico tra entrambi i lati poiché è stato trasferito in modo sicuro a un client ed entrambi i lati ora hanno quel segreto noto solo a loro.
-
Dopo la fine di una sessione (l'utente si disconnette) la chiave di sessione non svolge alcun ruolo e non viene utilizzata per altre sessioni (viene generata in modo casuale e la probabilità che la stessa chiave venga generata due volte è trascurabile).
È una descrizione molto semplificata, ma renderebbe almeno le cose un po 'più chiare.
Ciò che accade è che la crittografia asimmetrica autentica solo un utente e aiuta a scambiare la chiave segreta in modo sicuro. Tutta la comunicazione viene quindi crittografata con la stessa chiave segreta di sessione di qualche cifrario simmetrico.
In base alla tua domanda sull'omissione dell'archiviazione di un segreto su un client e sull'utilizzo di un trasferimento sicuro di sola andata:
-
ssh è un protocollo di comunicazione e lo schema sopra descritto fa parte della sua "modalità operativa". Non può essere modificato (correggimi se sbaglio)
- se vuoi solo spingere alcuni dati su un host remoto senza nemmeno autenticare il mittente (che è strongmente sconsigliato) puoi capire qualcosa come uno script di shell che crittografa i dati con qualche chiave pubblica (lato client,
gpg è un modo per andare) e lo invia su un telnet a un server che lo decrittografa con la sua chiave privata (di nuovo gpg ).
Sebbene il modello sopra descritto possa essere reso sicuro con una quantità di sforzo sufficiente ( hmac , digesti, firma, ecc.) ha davvero poco senso preoccuparsi di tutto questo, dato che devi ancora memorizzare secret da qualche parte ( questa volta è sul lato server, o anche su entrambi i lati se viene usato qualcosa come hmac ).