For ssh, ssh keys.

For https, webauthn is the way to do it, though services are relatively rare, particularly for self hosting, partly because browsers are very picky about using a domain name with valid cert, so browsers won't allow them by ip or if you click through a self signed cert

Have you heard of ssh keys?

For many places, it’s operational inertia. If you’ve had a hosting account at the same place since 1998, you’re bound to still have username/password access to services like FTP even though other (and better) options exist.

And then there is the issue of sole control. Many greybeards like myself still run traditional username/password auth on services because,

1. We have whitelisted our IP address, and if dynamic, keep that whitelist updated
2. That outside of said whitelisting, the service is a quasi-honeypot meant to protect the machine as a whole. Any connection made from outside the address space of my ISP, by anyone else, is by default considered malicious, and is banned instantly as a precaution. They don’t even get the opportunity to attempt a login; merely connecting to said service is sufficient evidence of hostile intent.

So while my setup is not ideal, it is ideal for myself. if I had anyone else as co-admin, or even clients, things would get stupidly complicated very quickly. But since it’s just me…

What you're looking for is probably something like certificate authentication, or mTLS. It exists, but it's kind of a pain to set up on client devices so it's not very common.

What's more common and easier to set up and is nearly the same thing, is passkey authentication. Same in-flight security characteristics, but you typically need to pass a simple challenge for your device to unlock it.

There are a bunch of self-hosted auth options for both

I think you are looking for SSH certificates.

I think the point here is that no-one uploads / enters a password/phrase/file.

Whatever you enter on the keyboard is hashed and the hash is sent. Depending on the protocol, sometimes it's time limited so no-one can record the network traffic and resend the data (replay attack)

Files (SSH keys, certificates, etc) are checked against a (usually) asymetric key exchange algorithm, so they can only compare what's sent if they have the corresponding key to decrypt the cipher.

The length of the password (or file) is basically meaningless. It's just how long it'll take someone to guess it (brute-force), but as the saying goes, you don't break into a house through the door, you go through Windows... ie the weakest link.

In your concept, the weakest link is the meatware: humans. We need ease of use, so, someone will store that file and it'll be compromised, so 64b, 128b or 512b doesn't matter, if they have the file, they're in.

Now... MFA... Now, that's more like it.

That’s what SSH keys are essentially.

Or using a hardware key for physical logins.

Both of those basically make your credentials a small encrypted key file instead of password.

Usernames and passwords really only exist as a “convenience”…..both for lazy users and bad actors.

This is how ssh works.

I'm an admin and using an SSH key is the most common way we log into servers.

Also the most common way I log in to self-hosted servers.

Congratulations, now your „password” (the 512-byte random key file) is stored as plaintext on your machine :)

With rate-limiting, non-trivial passwords are not viable to be brute-forced, so making them larger just doesn’t give you much.

Another one: The UX on browsers for managing password is far more developed, and the services you selfhost are accessed via a web browser.

I have no servers that accept external password-login. All use SSH keys.

If you mean the apps you run on the servers, many can use an OAUTH server that you then host for SSO.

mTLS (mutual TLS) is actually quite common out there. And SSH certificates moreso than public keys.

So clients get issued certificates that they can authenticate with. TLS for HTTPS but both ways. It sounds like this is what you're asking about?

You can (and should) just use a password manager to generate and store ~64 byte keys which have roughly the same amount of security.

If you're talking about websites, look in to mtls

1. You need the file everywhere. So when lunch time on work I can't login, it is not my computer but the company machine. Yes, i have my smartphone with me I dont want to send that file to work.
2. Easier with password. Easy to setup and to reuse a long password that you already have.
3. My ssh server is not reachable easily. Ip restrictions goes a long way and Wireguard is good.

As others have mentioned there are ssh keys and generally you can and should of course use a password manager.

However there is IMHO a huge blindspot of people using only SSH keys to long in, and that is that your day-to-day dev PC is actually more likely to be compromised in some way than the server that only runs specific, relatively well defined applications and overall just has less attack surface. And the ssh keys on your dev PC are really not very securely stored and thus quite easily compromised.

Hardware keys are of course a better solution, but I would personally recommend to use a 2FA solution that prevents access even when one factor (ssh keys or passwords) is compromised.

I think because there are ways to protect your entire systems with cryptographic keys - there's no need for individual applications to do that themselves. You can either only make your network accessible via an SSH tunnel (which would then use SSH-Keys), use a VPN or use mTLS which would require you to install a cert into your browsers key storage.

There's many good solutions to this problem - no need for individual applications to do it themselves.

It's a pain to manage. If you want to change it, you have to go to each server and update it manually, if you don't already have automation. If you do have automation, that's another thing you have to set up and manage. And all that for not much gain.

Check out TLS client certificates.

I believe this is what WebAuth Passkeys are.