3

Setup:

OpenSSH running on my server and JuiceSSH on client mobile device. Password authentication is disabled and private key is stored encrypted inside JuiceSSH dedicated memory.

Situation:

I want to connect to my server from an untrusted network (eg. public Wi-Fi on the bus or in the mall). The network is an open network and insecure, it may be possible that malicious 3rd party eavesdrops the connection and captures the data being sent and received.

Question:

In the above situation:

  • can the eavesdropper gain access to my server?
    • if yes - how would he achieve that and how could I prevent it?
    • if no - what mechanism is preventing this sort of attack?
  • how would the answers change if I were using passwords instead of keys?
ISMSDEV
  • 3,272
  • 12
  • 22
Reverent Lapwing
  • 133
  • 3
  • You might find this answer: https://security.stackexchange.com/a/9389/89876 useful - in particular, note that the key itself is never sent, just the ID – Matthew Jun 20 '17 at 13:04
  • 1
    The entire purpose of SSH is to be secure on untrusted networks... – Neil McGuigan Jun 20 '17 at 17:44

2 Answers2

1

can the eavesdropper gain access to my server?

if no - what mechanism is preventing this sort of attack?

No - The connection used to communicate the authentication is secure from eavesdropping using Diffie-Hellman key exchange as part of the process and digitally signing the protocol steps as proof that tampering hasn't occurred. Read the following: How does SSH use both RSA and Diffie-Hellman?

how would the answers change if I were using passwords instead of keys?

A password will likely lower the "brute-force-ability" of gaining access to the server, as your password is likely to be a lot lower in bits than the keys used.

Community
  • 1
ISMSDEV
  • 3,272
  • 12
  • 22
  • Thank you, but I was hoping for more detailed answer, see my edit. – Reverent Lapwing Jun 20 '17 at 13:05
  • Just updated my answer as well. Just editing now – ISMSDEV Jun 20 '17 at 13:06
  • That is not true. The DH does not prevent any of the attack by itself. The public key authentication (and the first saying "yes" to verification of server host key finterprint) does because only then you can verify you are connecting to the correct host. – Jakuje Jun 20 '17 at 14:45
  • Which is why I added "digitally signing the protocol steps as proof that tampering hasn't occurred" Which is proof you have the matching public key to the private key based on accepting the fingerprint of the servers key at the start. That used with DH provides authentication. – ISMSDEV Jun 20 '17 at 15:05
0
  • can the eavesdropper gain access to my server?

No.

  • if no - what mechanism is preventing this sort of attack?

The public key cryptography. When you were connecting to that server for the first time, you stored its public key. With every other connection the client verifies that the server has the corresponding private key (by requesting a signature of some data). If the server provides different key or fails to provide valid signature, the client should not continue to connect (I am not familiar with JuiceSSH, but I hope it is implemented correctly).

  • how would the answers change if I were using passwords instead of keys?

None.

Jakuje
  • 5,389
  • 17
  • 31