Cosa blocca un server SSH dagli accessi MITMing?

Come indicato nella risposta accettata, la firma viene determinata utilizzando la chiave privata su varie parti di dati:

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

La firma si trova su un "identificatore di sessione" che è unico per quella connessione.

Come per RFC 4253 :

The exchange hash H from the first key exchange is additionally used as the session identifier, which is a unique identifier for this connection. It is used by authentication methods as a part of the data that is signed as a proof of possession of a private key.

Questo identificativo di sessione sarà unico per la connessione client --> server , quindi la stessa firma non potrebbe essere utilizzata sulla connessione server --> server , mitigando qualsiasi attacco di riproduzione contro un secondo server SSH.

Quello che segue è un'esplosione interistituzionale dei rischi su un server SSH malevolo, ma non fa capire la domanda posta.

Su un server SSH dannoso tra te e una macchina mirata esegui i seguenti rischi (teorici)

Prima alcune definizioni:

• ServA = Il server SSH dannoso con intenzione di causare danni al tuo target o a yuu.
• ServB = La seconda macchina con cui ti connetti.
• You = L'utente che si connette prima a Serva che a ServB.

Alcuni dei rischi sono:

• Hijack di connessione: poiché ServA ha tutte le opportunità per manipolare la connessione con ServB può ingannare You nel pensare di connetterti con ServB quando in realtà imposta una connessione separata e solo pipe a te. Al termine, intercetta l'ultima chiamata 'exit' / 'logout' e mantiene la connessione per proprio uso.
• Registrazione di connessione: simile a Hijack di connessione tranne che ora tutto ciò che fa è registrare la tua attività. Ciò potrebbe rivelare password utente / accesso root / Altre informazioni sensibili.
• Connection Injection: questo è il contrario, ora ServA prende you invece di fare qualsiasi cosa su ServB . Cerca di indurti ad aprire una porta sul tuo computer o ad aprire una connessione al Proprietario malevolo per i suoi usi.

Per rispondere alla domanda posta:

Se l'agente di autenticazione è 'inoltrato' tramite la connessione SSH, il mio bit di risposta da me sopra entra e può essere utilizzato.

Se l'agente di autenticazione non viene inoltrato (predefinito) rispetto a ServB ha solo le credenziali fornite per accedere a quel server. supponendo che ci sia qualcosa di diverso (con un ssh-key sono come spiegato da @SilverlightFox) e supponendo che non ci sia alcun account compromesso su ServA a cui ServB ha accesso attraverso altri mezzi, Questo non può accadere. poiché il tuo SSH-client e il server SSH remoto rifiuteranno il processo di autenticazione errato.