10

I realise this question is subjective.

I am curious about the intelligability of an SSH password when an SSH tunnel is created. Does the secure session begin once the password has authenticated, or is the password itself encapsulated in this secure connection?

After an interesting debate in the office this morning, and aside of the possibility of an SSH password becoming compromised on a client with a keylogger, I am curious as to the possibility that an SSH password could also become compromised using packet sniffing tools on the LAN, or installed on any proxy between the Client and the Server. It's opened up a wider debate about the wisdoms of logging into private services (like a home NAS, or email) via an SSH tunnel whilst logged onto a client operating behind a/several intermediate proxy/ies. (ie, at work), especially with claims that tools such as Ettercap are capable of spying into SSH packets.

I assume that the same considerations could be made of SSL/HTTPS where a website does not parse the password into a one way hash such as MD5?

Your musings will be most appreciated.

Thanks.

8bitjunkie
  • 12,793
  • 9
  • 57
  • 70
  • 3
    This is not a programming question. – Raoul Jul 05 '11 at 10:12
  • 1
    Regarding HTTPS, there are similar questions: http://stackoverflow.com/questions/3911906/encrypting-http-post-data/3923617#3923617 and http://stackoverflow.com/questions/3837989/sending-sensitive-data-as-a-query-string-parameter/3840144#3840144. The whole request is sent over SSL/TLS (including request path, headers and body). The transmission of the password is protected, even when sent in clear (via a form or HTTP Basic). – Bruno Jul 05 '11 at 10:36
  • I should clarify what I've just said: "The transmission of the password is protected, even when sent in clear", by this I mean, even when the password isn't encrypted at the application layer (HTTP Basic auth is just an encoding, and passwords typed in forms are sent as-is within the form data). It's effectively not sent in clear, precisely because it's all done over SSL/TLS (as usual, if appropriate cipher suites are used). – Bruno Jul 05 '11 at 12:02

2 Answers2

18

Excerpt from the manpage of openssh:

Finally, if other authentication methods fail, ssh prompts the user for a pass‐ word. The password is sent to the remote host for checking; however, since all communications are encrypted, the password cannot be seen by someone listening on the network.

Peder Klingenberg
  • 37,937
  • 1
  • 20
  • 23
6

SSH is not named "Secure Shell" for no reason :).

SSH uses public-key cryptography for authentication, which is by itself pretty secure. If we assume that the attacker doesn't have the private keys of the user and the ssh daemon -- the password cannot be decoded by merely listening on the network.

This protocol, just like most others doesn't protect you from attacks from other sides. There are several combinations of social engineering and Man in the middle attacks like the SSH version downgrading attack and the DNS Spoofing attack.

Liudmil Mitev
  • 464
  • 2
  • 6