4

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.
Improve this question
5
  • Do you mean a normal ssh Server in the middle, tricked into doing something malicious? or a malicious ssh Server beeing connected to in the first case?? – LvB May 24 '15 at 13:25
  • 1
    @LvB The first SSH server is malicious, the second one isn't. – heinrich5991 May 24 '15 at 13:28
  • 1
    On the user side of things, assuming that the user's very first login to this server was not MITMed, a later MITM will likely generate a warning like this one: jamauai.files.wordpress.com/2013/03/ssh-warning.png?w=487 – tlng05 May 24 '15 at 14:30
  • @user54791: Note that this isn't the traditional MITM, you're talking with the server you want to be talking with, just that the server itself is also connecting to others. – heinrich5991 May 25 '15 at 2:13
  • I'll note here that the described scenario can absolutely happen if SSH-agent forwarding (ssh -A) is enabled when connecting to an untrusted or compromised server, and the attacker knows the address of another server which uses one of the keys shown to the first server. – Seldom 'Where's Monica' Needy Apr 27 '16 at 20:45
4

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.

Improve this answer
6
  • If I'm the malicious SSH server, why can't I force the same session identifier on both connections? To the client, I pretend to be the second SSH server and vice versa. – heinrich5991 May 24 '15 at 11:01
  • 2
    @heinrich5991: The session identifier is a hash that combines data chosen by the client with data chosen by the server. Your malicious server does not have full control over the session identifier for either of the connections. – hmakholm left over Monica May 24 '15 at 12:14
  • @HenningMakholm: Does that mean that the verification of the fingerprint of the public key of the server isn't necessary in order to make the authentication secure? – heinrich5991 May 24 '15 at 13:30
  • @heinrich5991 It depends. An MITM could pass the encrypted data verbatim between a legitimate server and a legitimate client which was not expecting to connect to that particular server. Say the client attempt to run a potentially destructive command on the rogue ssh server, if server public key is not verified the rogue ssh server could cause the command to get executed on a legitimate server instead. But apart from this case connecting without validating server public key is a much smaller risk when public key authentication is used. – kasperd May 24 '15 at 13:40
  • 1
    @kasperd: So that means that all a rogue SSH server can potentially choose (at the start of the session) to do is forwarding all commands to a legitimate SSH server that the user has access to (which the user probably doesn't anticipate). – heinrich5991 May 24 '15 at 13:45
0

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.

Improve this answer
4
  • I believe you answered the wrong question, in your terminology, I asked what happens if you connect to the rogue ServB (with the intent to connect to that ServB) but that server forwards your connection request to the legitimate ServA where you have an account but don't want to connect to right now. – heinrich5991 May 24 '15 at 14:23
  • 1
    than yes I have answered the wrong question. – LvB May 24 '15 at 14:42
  • 1
    Wow, there are 5 spelling errors in this answer's opening sentence. – user49075 May 25 '15 at 9:50
  • We are not all English native speakers or even language experts. If you can fix an spelling error please fix it not complain about it ;) Also, were not all using the same spelling book (not the whole world uses American-English) – LvB May 25 '15 at 11:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.