What stops an SSH server from MITMing logins?

Question

When I read this question about what gets signed with the private key by the client I wondered: What stops the following scenario from happening:

1. A client connects to an SSH server.
2. The SSH server knows that the client also has an account on a second SSH server. It connects to that second SSH server, providing the authentication challenge ("session identifier") of the second server to the client.
3. The client signs the the authentication requests, sends it to the first SSH server.
4. The first SSH server forwards the signed authentication request to the second SSH server and has access to the second SSH server.

Answer 1

As noted in the accepted answer the signature is determined using the private key over various pieces of data:

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

The signature is over a "session identifier" which is unique to that connection.

As 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.

This session identifier will be unique to the client --> server connection so the same signature would not be able to be used on the server --> server connection, mitigating any replay attack against a second SSH server.

Answer 2

What follows is an interisting explenation of risks on a malicous SSH server but does nto awnser the question asked.

On a Malicious SSH server in between you and a targeted machine you run the following (theoretical) risks

First some definitions:

• ServA = The malicious SSH server with intend to cause harm to your target or to yuu.
• ServB = The Targeted second Machine you connect with.
• You = The user that connects first to ServA than to ServB.

Some of the risks are :

• Connection Hijack: since ServA has all the opportunity to manipulate the connection with ServB it can trick You into thinking you connect with ServB when actually it set up a separate connection and just pipes it to you. After your done it intercepts the last 'exit'/'logout' call and keeps the connection for its own use.
• Connection Logging: Similar to Connection Hijack except now all it does is log your activity. This might reveal user passwords / root access / Other sensitive information.
• Connection Injection: This is the other way around, now ServA tricks you instead of doing anything on ServB. It tries to get you to either open a port on your machine or have your machine open a connection to the Malicious Owner for its uses.

To answer the Question asked:

If the Authentication Agent is 'forwarded' over the SSH connection than my answer bit from me above kicks in and can be used.

If the Authentication Agent is not forwarded (the default) than ServB only has the credentials you supplied to log into that server. assuming there different (with a ssh-key they are as explained by @SilverlightFox) and assuming there is no compromised account on ServA that ServB has access to through other means, This can not happen. since your SSH-client and the remote SSH-server will reject the incorrect Authentication process.