RFC 4252 fornisce linee guida su come l'autenticazione della chiave pubblica dovrebbe funzionare, ma non è del tutto specifica sull'ordine esatto di lo scambio. Detto questo, nei commenti si afferma che OP non è interessato alle RFC, ma piuttosto ai dettagli di implementazione di "SSH su Linux", che si riferisce a OpenSSH nella maggior parte dei casi.
Collegandoti a un host remoto su SSH con il flag verboso -v , di solito vedrai quanto segue per ogni chiave:
debug1: Offering RSA public key: .ssh/id_rsa.pub
Inoltre, possiamo consultare il codice sorgente . Dopo una rapida panoramica, è rilevante quanto segue:
if (PRIVSEP(user_key_allowed(ssh, pw, key, 1, &authopts)) &&
PRIVSEP(sshkey_verify(key, sig, slen, sshbuf_ptr(b),
sshbuf_len(b), NULL, ssh->compat)) == 0) {
authenticated = 1;
}
La funzione user_key_allowed controlla la chiave in un file di chiavi autorizzato, mentre sshkey_verify sembra verificare la firma di qualche buffer.
Combinando queste informazioni, sembra che il client utilizzerà tutte le sue chiavi fino a quando il server non ne accetta una. Ciò è anche evidente dal fatto che avere più chiavi presenti durante un singolo tentativo di connessione può apparire sul server come tentativi di autenticazione multipli dal momento che tutte le chiavi sono provate.
Inoltre, vedi i commenti di @ nbering per i dettagli sulle sfide / firme.
Modifica: Ecco un esempio in cui ho diverse chiavi, e solo il terzo provato è accettato dal server. Utilizzando -vvv :
debug1: Next authentication method: publickey
debug1: Offering public key: RSA SHA256:QfriqWH2S2uD6wHbxTFSudppOcJ51bB5ABr8ICrUhL8 .ssh/id_rsa2
debug3: send_pubkey_test
debug3: send packet: type 50 # SSH_MSG_USERAUTH_REQUEST
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51 # SSH_MSG_USERAUTH_FAILURE
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering public key: RSA SHA256:3M8bnhs+jGJm8X2cgnWzzMrfoeT3WmDkSp8AEr751Sk user@laptop
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering public key: RSA SHA256:CQeP9lcYBVqV11Rn8Ca4Sv+W8l8uU63WQ4TpyG5ZMmI user@laptop
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 60 # SSH_MSG_USERAUTH_PK_OK
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug2: input_userauth_pk_ok: fp SHA256:CQeP9lcYBVqV11Rn8Ca4Sv+W8l8uU63WQ4TpyG5ZMmI
debug3: sign_and_send_pubkey: RSA SHA256:CQeP9lcYBVqV11Rn8Ca4Sv+W8l8uU63WQ4TpyG5ZMmI
debug3: send packet: type 50
debug3: receive packet: type 52 # SSH_MSG_USERAUTH_SUCCESS
debug1: Authentication succeeded (publickey).
Di nuovo segue da vicino RFC 4252 , pagine 8-9.