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

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.

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

interesting, thanks. turns out there are even patches for ssh! 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-th... gives some details.

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.

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.

about password auth - you're wrong (AFAIK). i even gave a reference in my original post. didn't you bother to check it?

I am wrong. No.

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?

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.