-1

SSH client and server using public/private key authentication, using the Diffie-Hellman key exchange.

Instead of SSH sending the authentication public keys across the wire, would like to per-distribute the public keys and skip sending it over the line - then, the rest of the protocol same.

Is there a predefined setting in SSH for this or does it require a more detailed change?

  • 1
    DH in SSH is used specifically to achieve forward secrecy and the keys are meant to be ephemeral. What do you want to achieve? – techraf Aug 3 '16 at 1:19
  • @techraf: the session key ("shared secret") is ephemeral - however, not the authentication keys. Looking for a way that a MITM cannot get a hold of the client public keys and spoof the server as a legitimate client. I understand that the MITM would still need the clients private key to encrypt messages, but the MITM could still try to send data to the server, as the server thinks he is the real client. – P.S. Aug 3 '16 at 1:35
  • 1
    Why would server "think he is the real client"? – techraf Aug 3 '16 at 1:38
4

In SSH:

  • DH keys are used to achieve forward secrecy, they are unique for each session and ephemeral - there is no need and no way to pre-distribute them
  • client authentication keys (RSA) already have the requirement to be pre-distributed - by placing the client public key in the user's authorized_keys file on the server
  • server authentication keys can be either pre-distributed by placing the server's public key in the user's known_hosts file or accepted manually by the user on the first connection

Clarifications from the comments:

Looking for a way that a MITM cannot get a hold of the client public keys and spoof the server as a legitimate client. [] the MITM could still try to send data to the server, as the server thinks he is the real client.

It could "try", but it wouldn't succeed. Public key is not a token which you present to the authenticating party to be matched. Public key is used by the authenticating side to decrypt the message sent and encrypted (signed) by the party being authenticated, thus ensuring it was encrypted with the corresponding private key.

Knowledge of a public key does not allow to impersonate the holder of the corresponding private key.

If someone "listening" acquires that clients public RSA key, won't they be able to use it to connect to the server? How would the server know if it is the actual clients RSA public key vs. someone else just using his public key?

Example: the server has three public keys configured for access pubA, pubB, pubC.

  • B sends a message encrypted with privB. The server receives an encrypted message and tries to decrypt it using the public key pubA--it gets gibberish. Then it tries to decrypt the message using pubB and this time gets a valid message. It means the message was encrypted using privB. The only entity that owns the privB is B, thus the server confirmed B is the sender and grants the permission to access.

  • Someone encrypts the initial message with pubB and sends it to the server. The server is not be able to decrypt it using pubB (because it needs privB, but only B owns the privB, not the server).

  • Someone sends pubB to the server, the server has no idea, what it is. It does not expect any key to be sent.

Above explanation is conceptual, the real key exchange algorithm is more complex as the content of the initial message must also be established

  • Regarding the client authentication key (RSA) - even though it is per-loaded in the authorized_keys file on the server, isn't it still being transmitted over on connection (then checked against the per-loaded) ? If someone "listening" acquires that clients public RSA key, won't they be able to use it to connect to the server? How would the server know if it is the actual clients RSA public key vs. someone else just using his public key? – P.S. Aug 3 '16 at 18:07
  • Example: the server has three public keys configured for access: pubA, pubB, pubC. The server receives an encrypted message, it tries to decrypt it using the public key pubA, but gets gibberish, then it tries to decrypt the message using pubB and gets a valid message. It means the message was encrypted using privB. The only entity that owns the privB is B, thus the server confirmed B is the sender and grants the permission to access. – techraf Aug 3 '16 at 20:41
  • If someone encrypted the initial message with pubB and sent it to the server. The server will not be able to decrypt it using pubB (because it would need privB, but the only owner of the privB is B, not the server). – techraf Aug 3 '16 at 20:44
  • If someone sent pubB to the server, the server would have no idea, what it is trying to do in the first place. It does not expect any key to be sent. – techraf Aug 3 '16 at 20:44
  • tried to clean up the question if you can bump up the point please... – P.S. Aug 9 '16 at 1:23

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.