[foxtrottbravo]

First and foremost, congratulations on bringing the project to this stage - I think it's an impressive piece of work.

I am in no way qualified to trample on your parade but two things came to my mind that pinch a personal nerve of mine and I would really like to have alleviated by you or the folks who know that stuff:

- if your Goal was "secure by default", why did you allow passwords in the first place? Following Caddys recipe would be more like SSH-Keys only, wouldn't it? Is there a reason other than compatibility?

- In that same avenue? Why allow such a thing as downloading authorized keys from a third party? Domain takeovers or account compromises on say Github are a thing - so again while it may be a nice usability aspect isn't that contrary to the secure by default pradigm?

Again thank you for your work and congratulations on the project - those above are just honest questions that came to mind which I would really like to be educated on

[m_sahaf]

> - if your Goal was "secure by default", why did you allow passwords in the first place? Following Caddys recipe would be more like SSH-Keys only, wouldn't it? Is there a reason other than compatibility?

Compatibility was the consideration. The presence of the password based authentication does not mean it is enabled by default. In fact, if you don't enable any of the authentication flows and don't explicitly set `no_client_auth` to `true`, the server will not accept any request at all! You have to explicitly set `no_client_auth` to `true` for the server to allow unauthenticated users to login. The default is: none of the authentication methods are configured, and `no_client_auth` is false (meaning do not allow clients without authentication).

> - In that same avenue? Why allow such a thing as downloading authorized keys from a third party? Domain takeovers or account compromises on say Github are a thing - so again while it may be a nice usability aspect isn't that contrary to the secure by default pradigm?

That was just an example, but the implementation doesn't only support github. It supports any HTTP/S URL you provide. The point was that the source of the keys may even be an internal HTTPS service within your network that applies its own logic for keys issuance and generation.

[getcrunk]

Passwords are not insecure. Certs have tradeoffs.

[tialaramex]

Passwords are a shared secret. I'm not sure I'd choose the word "insecure" but only because it's too black and white when the reality is more nuanced. They are clearly worse than doing public key auth which is the alternative and is Mandatory To Implement in the SSH (SecSH) RFCs.

Nobody said anything about requiring certificates in SSH, just public keys as authentication.

[tptacek]

No they don't. Passwords are worse than certificates or keypairs, categorically.

[dspillett]

Good passwords are usually not insecure. But if you give your password to a host that you don't 100% trust (i.e. that you didn't setup yourself locally) you have potentially shared that password and if you've reused it anywhere the other wheres are potentially compromised.

If you give you public key to be installed to allow access, even if the host (or any system you are using to build/interact with it) is compromised your private key and any other hosts that accept authentication that way are fine.

How much difference this makes to you depends upon your threat model and how much extra threat you are willing to accept for a little convenience, of course, but key based auth is demonstrably more secure than passwords for some circumstances and no less secure in others.

Then again given that very few people bother actually checking host fingerprints on first connection, then proceed to send important data to that unverified host, is the password/key issue the first thing we need to fix?

[dewey]

I don't read it as "passwords are insecure" but as having defaults that force people into using it in ways that are harder to mess up.

Re-using an insecure password is easy, using a key wrong is harder.