Much of security improvements these days are not just enabling better security, but making them easy and default.

Sure it's possible to: have a strong password, use it only for a single machine, keep it in a good password safe, never reuse it anywhere, have the discipline to not make it short/easy to type/easy to remember, change it every time a server is compromised, etc....

Or you could get all that for free with public keys. Yes a private key is like a very long password, but the important part is that it never leaves the client side and it's safe to use on every computer you want access to without the hassle of remembering one password per server.

If you access many machines, how will you know when one is compromised? How will you prevent an attacker from logging in as you?

Public keys really are the better way to handle user auth, less of a minefield for regular users.

> If you access many machines, how will you know when one is compromised? How will you prevent an attacker from logging in as you?

Even better is to use SSH certificates. That way you don't have to deal with authorized (usually permanent) keys.

Once the SSH CA is installed in the host, the client can generate temporary asymmetric keys and sign them with the CA key before every connection.

There are a few ways to set up this scenario, here's one using Vault:

https://www.vaultproject.io/docs/secrets/ssh/signed-ssh-cert...

Not sure that's any better in security terms. It has some ease of use and central management benefits but also some significant complexity (setup and maintenance of a CA).

My setups just used puppet to manage a authorized key directory on each machine (basically one line of code), assuming you have a working puppet setup of course.

I'd consider either approach significantly more secure than passwords which is a much worse approach.

> Public keys really are the better way to handle user auth, less of a minefield for regular users.

I'll go along with that, thou i consider a secret that resides in my brain vastly more secure than one residing on my disk.

I 100% agree. But with ssh (ideally) the passphrase never leaves the computer you are physically touching.

With passwords you are sending it to remote computers where it could be compromised. Thus the standard practice of forcing all users to change their passwords when a server is compromised.

I've come to realize that if I don't use a password at least once per month, I will forget it.

...so, this isn't great advice either. Password vaults are important..... at which point, you can just use a complex unique password.

Okay, so use the 56 bits that you can store in your head as a passphrase to control the 256 bits (for ed25519) on your disk.

It’s not only bad passwords you’re battling against but social engineering and poor administrative practices.

I’m comfortable with telling people to turn off password auth on their sshd’s and treat password auth as the exception rather than the rule.

Also, it’s generally a nicer user experience.

There is a very significant distinction - a private key does not (or should not) leave the user's computer. A private key is very long password that is magically¹ never revealed to anyone during normal use, only it's accessibility is proven.

If the user does not verify the remote host's fingerprint (vast majority doesn't), they could be sending the password to an attacker / honeypot or just wrong server / password. And if they reuse passwords, server can record passwords and someone could try them elsewhere.

If you're using passwords, it is very likely the password was copy-pasted to an inappropriate host (or passwords common for many hosts). It is also very likely the first connection to a server from a given computer was without verifying the remote host (server fingerprint), users are likely try and accept all kinds of things if they connection doesn't work, and I've even seen people disable host key verification so they wouldn't be bothered when a server is reinstalled / ip is reused.

Local accessibility of private keys is a significant issue, but if a program can read .ssh/..., it can usually also alias ssh=store-pasword-and-ssh, so using password doesn't help that much, vs. it's other issues.

If you're using passwords for yourself, it may be manageable, but I never give other people ssh login access using passwords.

¹ using asymmetric cryptography

> A private key is just a very long password that is stored on disk

Absolutely 100% not. You're missing the most important aspect of PKI based authentication, the asymmetry. With symmetric authentication technologies, like passwords, the only way a user can authenticate is to hand over to the server (which might be malicious) everything that the server needs to impersonate that user.

Practically, this means that when I root the Linux server in your environment, and start up 3snake, I'm going to start collecting the passwords of every person who logs in, and I can use those passwords to escalate privileges around the network. This is not even a little bit possible in an environment where SSH key authentication is enforced.