2

I am a bit confused on how SSH encryption works.

From reading this question, I see you can use a private key to authenticate with the -i flag.

I also know think that SSH encrypts data using private and public keys.

I am creating an application that will setup and SSH Tunnel and SOCKS5 Proxy for clients. Authentication occurs by using the -i and specifying an included private key. The idea of this is to ensure that all traffic is encrypted.

I am am afraid that by all clients having the same private key they may be able to decrypt traffic from other clients so my question is the following:

Client A: ssh user@sshtunnel.com -D 5464 -I /path/to/the/private.key -N

Client A: Makes request to http:// unsecured.com with POST data containing Username and Password

Attacker B: Obtains /path/to/the/private.key

In this scenario could Attacker B decrypt the SSH traffic from Client A and view the Username and password in plaintext?

JBis
  • 640
  • 5
  • 17
  • I think that you may not have a complete understanding of how encryption and authentication work. You may want to dive deeper into the technical aspects of those topics and then rephrase your question. – xorist Aug 27 '18 at 18:41
  • @l1thal What inaccuracies exist? – JBis Aug 27 '18 at 21:24

1 Answers1

4

TL;DR: In SSH your private key is not used for encryption at all, it's only used to prove who you are. Each new connection to the server will establish a different encryption session key.

Here are some good primers on how the SSH handshake works:

I also know think that SSH encrypts data using private and public keys.

Actually, the public and private key are only used for the authentication part of the SSH handshake, not for the encryption part. From those articles, the SSH handshake comes in two steps:

  1. Set up encryption: Use Diffie-Hellman to establish a shared encryption key that both the client and server know, but someone eavesdropping can't know.
  2. Authentication: both client and server use their public keys and private keys to prove that they are who they say they are.

Authentication occurs by using the -i and specifying an included private key. The idea of this is to ensure that all traffic is encrypted.

How did you jump from authentication to encryption? Your traffic will be encrypted even if you use password-based authentication because authentication and encryption are unrelated parts of the SSH handshake.

I am am afraid that by all clients having the same private key they may be able to decrypt traffic from other clients

Each new connection to the server will establish a different session key using the Diffie-Hellman key exchange method. This is independent of your private key. To the best of my knowledge, each session is totally isolated from the others, even if they are for the same user or use the same private key.

Mike Ounsworth
  • 57,707
  • 21
  • 150
  • 207
  • Can you explain the "probably" part? I am guessing you mean "Due to the way the session keys are generated, there is an extremely small chance that two of the same keys will be the same, although it is still possible", if not can you explain. And thanks for your explanation. Will take a look at the links soon. – JBis Aug 27 '18 at 22:24
  • @JBis Oh, it's just that I've been in the security industry long enough and seen enough vulnerabilities come and go to never make absolute statements. I'm not discounting the possibility of some unknown bug in the openssh code, or some way to misconfigure it that ends up leaking data between two sessions for the same user. I'll adjust the wording ;) – Mike Ounsworth Aug 27 '18 at 22:31
  • 1
    Lol. Theres n̶e̶v̶e̶r̶ probably never a defiant thing when it comes to security. ;) – JBis Aug 27 '18 at 22:35
  • @JBis Another thought: unix doesn't attempt to add protections between two processes owned by the same user. So if all your clients are SSH'ing to the same server as the same user, then anyone with the private key can log in and see `bash_history` for all SSH sessions, cache files in `/tmp` for all SSH sessions, attach a debugger or do a memory dump on the process for any other active session, etc. Depending on your requirements, that may count as cross-session information leakage, even though it's not directly related with SSH or the private key. – Mike Ounsworth Aug 27 '18 at 23:09
  • 1
    Thanks for the info! I have ensured that the shell is disabled. They should only be able to access forwarding. Not specifying the `-N` results in an immediate disconnect. Will keep in mind for future reference though, – JBis Aug 27 '18 at 23:14