Come funziona l'autenticazione con chiave pubblica ssh?

I dettagli dell'autenticazione dipendono dalla versione del protocollo e dal tipo di chiave. In tutti i casi, c'è sempre una sfida, con un po 'di casualità per evitare attacchi di replay. Quando la chiave utente è di tipo DSA, una vera firma digitale è necessariamente coinvolta, poiché DSA è un algoritmo di sola firma. L'articolo a cui ti colleghi mostra qualcosa che presuppone che la chiave utente possa fare la crittografia asimmetrica; Immagino che questo sia qualcosa che ha fatto SSHv1 (in SSHv1, tutte le chiavi erano RSA e RSA può fare la crittografia asimmetrica). Per il protocollo corrente (SSHv2), l'autenticazione client basata su chiave pubblica è specificata in RFC 4252 , sezione 7.

Il concetto di base rimane lo stesso: il client dimostra il suo controllo della chiave privata eseguendo un'operazione che richiede la conoscenza di quella chiave, ma tale che l'operazione "inversa" può essere eseguita con la chiave pubblica che si trova nel .ssh/authorized_keys sul server.

In breve:

• SSHv1: il server crittografa un messaggio su una chiave pubblica memorizzata in authorized_keys , il client deve decrittografarlo e restituire il suo checksum (modificato da un ID di sessione)
• SSHv2: il client firma un messaggio (a seconda dell'ID di sessione) e trasmette la firma senza il messaggio ma con la chiave pubblica utilizzata. Il server quindi ricrea il messaggio e verifica la firma (a condizione che la chiave pubblica sia effettivamente in authorized_keys )

Il documento PROTOCOL.agent riepiloga questo:

Protocol 1 and protocol 2 keys are separated because of the differing cryptographic usage: protocol 1 private RSA keys are used to decrypt challenges that were encrypted with the corresponding public key, whereas protocol 2 RSA private keys are used to sign challenges with a private key for verification with the corresponding public key. It is considered unsound practice to use the same key for signing and encryption.

Ecco la sezione pertinente di SSHv2 da RFC 4252 :

To perform actual authentication, the client MAY then send a
signature generated using the private key. The client MAY send the
signature directly without first verifying whether the key is
acceptable. The signature is sent using the following packet:

  byte      SSH_MSG_USERAUTH_REQUEST
  string    user name
  string    service name
  string    "publickey"
  boolean   TRUE
  string    public key algorithm name
  string    public key to be used for authentication
  string    signature

The value of 'signature' is a signature by the corresponding private key over the following data, in the following order:

  string    session identifier
  byte      SSH_MSG_USERAUTH_REQUEST
  string    user name
  string    service name
  string    "publickey"
  boolean   TRUE
  string    public key algorithm name
  string    public key to be used for authentication

When the server receives this message, it MUST check whether the
supplied key is acceptable for authentication, and if so, it MUST
check whether the signature is correct.