4 ms·

steal your password i had always assumed that the protocol somehow protected your password, but reading the spec at http://www.ietf.org/rfc/rfc4252.txt http://

steal your password i had always assumed that the protocol somehow protected your password, but reading the spec at http://www.ietf.org/rfc/rfc4252.txt http://www.ietf.org/rfc/rfc4252.txt that's not the case (and i've pretty much convinced myself it's not possible to do better). learn something new every day... [apart from the reference above, someone else here claims to be logging these things.]

Osmium 13y ago
Huh. I hadn't actually thought that the protocol itself could protect you (I only left my comment based on what I'd read elsewhere; I don't know anything about it otherwise). So hypothetically speaking, if the protocol did protect your password from being stolen, what would be the actual threat of a piece of malware specifically pretending to be SSH?
- sp332 13y ago
  If you use "sudo foo" in the remote shell, and then type your password, it could steal that. Or even if you somehow obfuscated your sudo password, it could change the command presented to sudo, so after you type your password, the new substituted command would be executed. Exaple: you type "sudo less /var/log/messages" but the fake-ssh tells the remote shell that you really typed "sudo email-me-all-your-data". Then the real sudo authenticates you, and executes the command you didn't type.
Hello71 13y ago
With "password" authentication method, the password is not transmitted to the remote server. (AFAIK) However, all modern sshds (AFAIK, at least OpenSSH) default to (publickey, keyboard-interactive). As the name says, keyboard-interactive sends your keystrokes, one at a time (bar buffering) to the remote server. This is required, for example, when using PAM, as PAM requires the actual authentication key.
- deleted 13y ago
  [deleted]
- andrewcooke 13y ago
  about password auth - you're wrong (AFAIK). i even gave a reference in my original post. didn't you bother to check it?
  - Hello71 13y ago
    I am wrong. No.
prutschman 13y ago
There exist ways for a client and server to convince each other they share a secret (such as a password) without giving an adversary enough information to infer the secret. Here is one such: http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol
- andrewcooke 13y ago
  does that work when it's a system password that exists in a hashed (scrypt) database? it seems like it would leave things open to someone stealing the hashed system password. if this can be made to work for ssh when using system passwords that would be very cool. but to my (inexpert) eye it seems unlikely (without relying on a trusted client). do you have a description for that case? the problem, in short, is that the password is not shared. the server does not know it - it only knows the hash. and the hash is not sufficient as a shared secret.
  - shawnz 13y ago
    I'm not an expert, but your question has interested me for quite a while as well, so I did some research. It seems that SRP does not require the plaintext password to be stored by the server. > SRP does not expose passwords to either passive or active network intruders, and it stores passwords as a "non-plaintext-equivalent" one-way hash on the server. Source: http://srp.stanford.edu/analysis.html http://srp.stanford.edu/analysis.html
    - andrewcooke 13y ago
      interesting, thanks. turns out there are even patches for ssh! http://srp.stanford.edu/links.html http://srp.stanford.edu/links.html but i get the impression that still doesn't mean that ssh can be made to work with system passwords without transmitting them (over an encrypted channel). i don't understand why - maybe srp requires a particular kind of hash? ah yes - this answer http://security.stackexchange.com/questions/23821/srp-can-the-client-authenticate-using-only-the-stored-hash http://security.stackexchange.com/questions/23821/srp-can-th... gives some details.
Dylan16807 13y ago
Even if it's not possible to improve the security of a single-server system, there is definite room for improvement in the real world. Assume for a moment that you have to transmit the password to the server instead of using proof of knowledge algorithms. This makes the server a potential point for stealing the password. This is of negligible risk in theory, because the server has access to itself by definition. But in the real world people reuse passwords. So in the real world you can improve security by hashing what the user types with server-specific data (public key?) and using that as the server-specific password. Then someone that can capture the password can only log on to that specific server.

Osmium 13y ago

Huh. I hadn't actually thought that the protocol itself could protect you (I only left my comment based on what I'd read elsewhere; I don't know anything about it otherwise). So hypothetically speaking, if the protocol did protect your password from being stolen, what would be the actual threat of a piece of malware specifically pretending to be SSH?

sp332 13y ago
If you use "sudo foo" in the remote shell, and then type your password, it could steal that. Or even if you somehow obfuscated your sudo password, it could change the command presented to sudo, so after you type your password, the new substituted command would be executed. Exaple: you type "sudo less /var/log/messages" but the fake-ssh tells the remote shell that you really typed "sudo email-me-all-your-data". Then the real sudo authenticates you, and executes the command you didn't type.

Hello71 13y ago

With "password" authentication method, the password is not transmitted to the remote server. (AFAIK) However, all modern sshds (AFAIK, at least OpenSSH) default to (publickey, keyboard-interactive). As the name says, keyboard-interactive sends your keystrokes, one at a time (bar buffering) to the remote server. This is required, for example, when using PAM, as PAM requires the actual authentication key.

deleted 13y ago
[deleted]
andrewcooke 13y ago
about password auth - you're wrong (AFAIK). i even gave a reference in my original post. didn't you bother to check it?
- Hello71 13y ago
  I am wrong. No.

prutschman 13y ago

There exist ways for a client and server to convince each other they share a secret (such as a password) without giving an adversary enough information to infer the secret. Here is one such: http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol

andrewcooke 13y ago
does that work when it's a system password that exists in a hashed (scrypt) database? it seems like it would leave things open to someone stealing the hashed system password. if this can be made to work for ssh when using system passwords that would be very cool. but to my (inexpert) eye it seems unlikely (without relying on a trusted client). do you have a description for that case? the problem, in short, is that the password is not shared. the server does not know it - it only knows the hash. and the hash is not sufficient as a shared secret.
- shawnz 13y ago
  I'm not an expert, but your question has interested me for quite a while as well, so I did some research. It seems that SRP does not require the plaintext password to be stored by the server. > SRP does not expose passwords to either passive or active network intruders, and it stores passwords as a "non-plaintext-equivalent" one-way hash on the server. Source: http://srp.stanford.edu/analysis.html http://srp.stanford.edu/analysis.html
  - andrewcooke 13y ago
    interesting, thanks. turns out there are even patches for ssh! http://srp.stanford.edu/links.html http://srp.stanford.edu/links.html but i get the impression that still doesn't mean that ssh can be made to work with system passwords without transmitting them (over an encrypted channel). i don't understand why - maybe srp requires a particular kind of hash? ah yes - this answer http://security.stackexchange.com/questions/23821/srp-can-the-client-authenticate-using-only-the-stored-hash http://security.stackexchange.com/questions/23821/srp-can-th... gives some details.

Dylan16807 13y ago

Even if it's not possible to improve the security of a single-server system, there is definite room for improvement in the real world. Assume for a moment that you have to transmit the password to the server instead of using proof of knowledge algorithms. This makes the server a potential point for stealing the password. This is of negligible risk in theory, because the server has access to itself by definition. But in the real world people reuse passwords. So in the real world you can improve security by hashing what the user types with server-specific data (public key?) and using that as the server-specific password. Then someone that can capture the password can only log on to that specific server.