Autenticazione reciproca del server SFTP

Autenticazione a SSH

L'autenticazione richiede due forme primarie, nome utente e password e autenticazione basata su chiave.

Esiste anche un controllo di autenticità eseguito quando il client si collega al daemon SSH confermando che la chiave pubblica attendibile non è cambiata confrontando l'impronta digitale presente nel database attendibile known_hosts e ciò che il server presenta. Se queste corrispondenze, la connessione continua, il server sfida per l'autenticazione e, una volta convalidato, viene stabilita la sessione completa.

Che cos'è l'autenticazione reciproca?

Prima di parlare di SSH, parliamo dell'autenticazione reciproca in un'implementazione tipica. Un'autenticazione reciproca TLS presenta i certificati sia al server che al client, confermando l'identità. Questo è comunemente usato nelle applicazioni B2B, come gli endpoint API. Ciò fornisce i vantaggi di PKI (crittografia in transito, controllo dell'integrità e revoca tramite responder CRL e OCSP) fornendo al contempo l'autenticazione dell'identità.

Che ne pensi di implementarlo in SSH?

Per impostazione predefinita, questo non funzionerà. Il client SSH si connette a un daemon SSH. Ciò richiederebbe che il server abbia le credenziali del client sul client. Confondere? Facciamo un passo indietro.

Utente (tu) - > Chiave SSH - > Server

Questo è un comportamento normale. Vogliamo capovolgerlo e instaurare fiducia nel retro:

Server - > Chiave SSH diversa - > Utente (tu)

Questo è pericoloso . Ci sono alcuni motivi per cui:

• Il compromesso del server consentirebbe di eseguire il pivoting sulla rete desktop aziendale o sulla rete domestica di un utente. Entrambe le situazioni sarebbero devastanti.

• Gli ACL nell'azienda non dovrebbero consentire che ciò accada. Ciò semplifica la rotazione e l'estrazione dei dati per un utente malintenzionato.

Conclusione

Questo è possibile, ma raramente fatto ed è pericoloso.

Se si esegue il seguente comando sul server SFTP (assumendo il percorso corretto)
ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub

Avrai un risultato simile al seguente:

2048 7c:d9:68:a7:de:ad:26:12:34:56:78:00:4a:9b:a2:b9 root@localhost (RSA)

Se salvi questa stringa di hash con il tuo cliente, puoi confrontarla alla prima connessione o se ti capita di incontrare il seguente messaggio:

The authenticity of host 'localhost (::1)' can't be established.
RSA key fingerprint is 3e:34:de:ad:55:55:55:66:89:ab:41:de:ad:46:20:16.
Are you sure you want to continue connecting (yes/no)?

Puoi quindi confrontare manualmente i due hash e se sono diversi saprai se non ti stai collegando al server corretto.

Nota: una volta stabilita la connessione per la prima volta, il client si occupa di questo confronto ogni volta che colleghi e salva i dati nel file .ssh/known_hosts per il confronto.

Detto questo, conoscere in anticipo l'hash della chiave del server consentirebbe all'utente del client di verificare che si connetta al server corretto.

È stato definito hostbased metodo di autenticazione in ssh protocol, che fondamentalmente è ciò che è nella domanda.

Questo metodo deve essere esplicitamente consentito:

HostbasedAuthentication yes
EnableSSHKeysign yes

in ssh_config , ma anche sul server (ma certamente non per tutti - il nome DNS convalidato è un buon inizio):

Host *.trusted.example.org
    HostbasedAuthentication yes
    EnableSSHKeysign yes

quindi imposta host globali conosciuti in known_hosts file su client e server con chiavi pubbliche valide dei peer (sostituiranno in pratica authorized_keys ).

L'ultima cosa è /etc/shosts.equiv , che limita chi può accedere e da dove.

Non sto dicendo che è una buona pratica, sicura o altro, ma esiste . Ma usare i certificati ssh è un approccio molto migliore.