passwords are a symetric key, hence if the server is compromised, so is the password. with asymetric keys, a compromise of the public key is no problem.
but you are right, key-files on a disk are more vulnerable to theft than secrets in your head. keyfiles with a password ontop are most secure but also most uncomfortable.
> passwords are a symetric key, hence if the server is compromised, so is the password
Pretty sure that’s not how it works, iirc passwords are stored one-way encrypted. And if it were true, then anyone with root access to a box could comprise every other (Unix) user’s key, which seems like a potentially bigger problem…
Passwords are (or rather should be) indeed stored using crypt. However at login the provided password needs to be compared to the hashed one, which means the clear text password needs to be rehashed. I am not sure this happens on the client.
Quick google led me to RFC4252[0], section 8 of which (as far as I understood) describes ssh auth sending password as UTF8 plaintext string (and the whole packet is encrypted at transport layer). While passwords in /etc/shadow are hashed, if someone got access to your server he can just put malicious listener that will catch this UTF8 string.
I'm not a SSH guru, so if I'm mistaken please shout at me ;D
A Password-Authenticated Key Exchange (PAKE) attempts to address this
issue by constructing a cryptographic key exchange that does not
result in the password, or password-derived data, being transmitted
across an unsecured channel.
I wouldn't worry about storage. Anyone with root access can modify the sshd daemon (along with imap, pop3, and whatever else) to log all the passwords received.
