upvote
Password gets sent to the server. Private key does not get sent to the server, and authentication protocol can be forwarded safely, enabling things like ssh-agent, FIDO SSH keys. This is solvable with passwords (see: augmented PAKE), but `PasswordAuthentication` isn’t that. But there are also settings where none of this really matters, yes, to be fair if that’s what you’re referring to.

SSH certificates are cool too.

reply
password doesn’t get sent to the server, hash does.

but I guess that the hash is always the same unlike with pub priv key mechanism.

reply
> password doesn’t get sent to the server, hash does.

Kind of irrelevant what gets sent to the server and what happens on the server.

Password is already easily defeatable long before it even leaves your computer, thanks to keyloggers and/or password manager breaches and/or old-school shoulder surfing (assisted in the 2026 era by covert filming and AI).

All of which are not vulnerabilities with hardware-backed keys which you don't even need a Yubikey for these days since most modern computers and smartphones have secure enclaves and/or TPMs. (Yubikeys are still great though).

reply
No, you are wrong. The password gets sent to the server. That said, I still enable passwords on servers, but don't ever share passwords between trust domains.
reply
What people think of as a very strong password often has <100 "security bits" of entropy.

Keys are usually at least 128 bits of entropy, and it's easy to take them up to 256.

Yes, both are a shared secret, but password auth - even with challenge-response - is weaker than key auth exactly because key auth provides more guess resistance.

reply
But the SSH keys are based on asymmetric crypto, not shared secrets.
reply
> What people think of as a very strong password often has <100 "security bits" of entropy.

The best password in the world will still be defeated by a simple keylogger or breach of your password manager.

reply
2^100 is a lot of things to try though
reply
Especially if you have Fail2Ban set up.
reply
> if you have Fail2Ban set up.

Worth noting that if you are running a remotely recent version of SSH it has everything you need built-in. No need for Fail2Ban on SSH these days if your config is fully modernised.

reply
Fail2Ban is kind of required unless one like running out of sockets and are unburden by high cpu and disk load.
reply
Huh? I run ssh (OpenSSH) on port 22 with root login enabled and no fail2ban on a single-core laptop cpu from fifteen years ago. The load average is 0.00 even with the small mail and web server that runs on it

What cpu and especially what disk load are you talking about? Also not running out of sockets, not sure if that's RAM-dependent (the box has 2GB)

reply
Password reuse is the problem. The password hash is stolen from some other site and brute forced offline.
reply
Same issue with key reuse. Unless you have a policy to rotate them and verify which host they login from, someone's unencrypted hard drive from 5 years ago is more likely to have a key than password.
reply
> someone's unencrypted hard drive from 5 years ago is more likely to have a key than password.

Even 5+ years ago, hardware-backed SSH keys were a thing (Yubikey). The only difference today is that its 100% easier to do keys properly because of the widespread commoditisation of secure enclaves in desktops and smartphones to support FIDO, its basically free of charge now because you're not obliged to buy a Yubikey.

reply
you claimed my favorite game's character name!
reply
deleted
reply