¿Qué detiene un servidor SSH de los inicios de sesión de MITMing?

Como se indicó en la respuesta aceptada, la firma se determina utilizando la clave privada sobre varios datos:

  

El valor de 'firma' es una firma de la clave privada correspondiente en los siguientes datos, en el siguiente orden:

 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 está sobre un "identificador de sesión" que es único para esa conexión.

Según RFC 4253 :

  

Se usa adicionalmente el hash de intercambio H del primer intercambio de clave   como el identificador de sesión, que es un identificador único para este   conexión. Es utilizado por los métodos de autenticación como parte de la   datos firmados como prueba de posesión de una clave privada.

Este identificador de sesión será único para la conexión client --> server , por lo que no se podrá usar la misma firma en la conexión server --> server , lo que mitigará cualquier ataque de reproducción contra un segundo servidor SSH.

Lo que sigue es una explicación interistente de los riesgos en un servidor SSH malicioso, pero no responde a la pregunta formulada.

En un servidor SSH malicioso entre usted y una máquina específica, corre los siguientes riesgos (teóricos)

Primero algunas definiciones:

• ServA = El servidor SSH malicioso con la intención de causar daño a su objetivo o a usted.
• ServB = La segunda máquina dirigida con la que se conecta.
• You = El usuario que se conecta primero a ServA que a ServB.

Algunos de los riesgos son:

• Conexión Hijack: dado que ServA tiene toda la oportunidad de manipular la conexión con ServB , puede engañar a You para que piense que se conecta con ServB cuando en realidad configura una conexión separada y solo tuberías para ti. Una vez que lo haya hecho, intercepta la última llamada 'salir' / 'cerrar sesión' y mantiene la conexión para su propio uso.
• Registro de conexión: similar a Connection Hijack , excepto que ahora todo lo que hace es registrar su actividad. Esto podría revelar las contraseñas de usuario / acceso de root / Otra información confidencial.
• Inyección de conexión: Esto es al revés, ahora ServA tricks you en lugar de hacer nada en ServB . Intenta que abra un puerto en su máquina o haga que su máquina abra una conexión con el propietario malicioso para su uso.

Para responder la pregunta:

Si el Agente de autenticación se "reenvía" a través de la conexión SSH, mi bit de respuesta de mi parte anterior se activa y se puede usar.

Si el Agente de autenticación no se reenvía (el valor predeterminado), ServB solo tiene las credenciales que proporcionó para iniciar sesión en ese servidor. asumiendo que son diferentes (con una clave ssh son como se explica en @SilverlightFox) y asumiendo que no hay una cuenta comprometida en ServA a la que ServB tenga acceso a través de otros medios, esto no puede suceder. ya que su cliente SSH y el servidor SSH remoto rechazarán el proceso de autenticación incorrecto.