> - 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.

Passwords are not insecure. Certs have tradeoffs.

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.

Strong aPAKES can allow passwords to not be shared secrets.

Of course they're super niche now and none of them are standardized so they're basically impossible to use, and SSH doesn't support them, so this is a pedantic nitpick instead of some sort of insightful observation.

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

> No they don't

SSH into one of your boxes from my machine real quick.

What's the use case for using your personal unix account on someone else's computer?

I've done it from work computers where the USB ports are disabled but I want to hit my personal dev machine at home to get at my notes and calendar.

I've established impromptu SSH tunnels from other people's machines to my local network so that I could watch my media on their TV.

If you dropped me naked on the other side of the planet I could get a copy of my identity documentation and access my email, bank accounts, etc from any internet connected machine I find.

You get that passwords over first-time SSH from untrusted computers or untrusted networks aren't safe at all, right? That posting those passwords is literally a sport at hacker conferences, and has been for over 2 decades?

This whole thread is a little alarming.

You get that waking outside isn't safe at all right? Mugging is as old as civilization and don't get me started on cars.

Life is about trade offs, if someone really wants to spend the time to get access to my home dev box then I may have to spend a couple days on the phone with the bank and restoring from my offline backups. Big whoop.

Your home is likely insecure from my standards. Do you have a firearm at the ready? Do you know how to use it? Does your family have codewords to communicate without letting others on to your plan? How hard is it to kick in your doors? Not just the front door, but the bedrooms. Do you have a dog to wake you in the night? How stocked are you, can you last a month with no resupply? Do you even have a panic room?

I protect what matters beacuse you can't protect everything.

How are we still talking about this? SSH doesn't work the way you appear to think it does. Passwords don't solve the first-use problem; in fact, the first-use problem makes passwords much less safe than keys.

Yes and your cheap hollow core door doesn't solve the ending the life of everyone you care about problem. Why are you more concerned about passwords than that?

I know the risks well, I don't find them to be worth the hassle of avoiding them.

Iirc ssh passwords aren't sent in the clear. Is that really the case?

Edit: I looked it up to confirm. First time password is encrypted analogous to tls

No, it's not analogous to TLS. TLS has trust anchors: the key exchange in a TLS handshake is secure, even on first contact with a server. The key exchange in a first-contact SSH handshake is trivially MITM'd. An attacker with control of your network (or, obviously, your machine) can simply steal your password.

I'm sorry I should have said it uses diffie hellman key exchange. And you are correct it can be mitm. I see that as its primary intrinsic weakness. (Password entropy, storage, are separate problems)

I would contrast this with the weakness of keys being that if the devs keys are compromised so are all the other servers he has access too. (I can memorize my passwords, or write them on a note card. Say what you will about that, it's out of band.)

In light of that the question as to what's best is your threat model. Poor opsec per dev or an upstream network sniffer.

Thanks for all your input all over this thread. I'm revisiting my convictions.

Would you disagree with I've said?

But you've now swapped out part of the authentication. If you want to claim that, for some threat models, "One password per server" is better than "One key" then, sure, so use "One key per server" and now keys are better again.

Also - I suspect this Caddy server doesn't support it, but OpenSSH does - you can use FIDO and then the keys physically are objects in the real world, from say Yubico or a dozen other vendors so now "losing the keys" is like losing your office keys, except that when they give you a new one they can trivially make the old one stop working.

A users keys are unlikely to be compromised singly. You would get them all. Whatever malware exfils the keys would take all that it finds.

My mail server crashed while I was on vacation without my laptop.

Of all the use cases I can imagine, enabling password logins just so I can meaningfully type my password into strange computers is among the least compelling.

How do you log into a server for the first time without a password? How do you log into a server from a brand new machine without access to your previous machine or sharing certs?

So there are three different scenarios wrapped up in this question and they're all interesting.

A. The server is new, and I'm setting it up presumably remotely e.g. in "the cloud". Ideally the autonomous setup should provision keys for me in this case, since they're public it's fine to even publish scripts which do this. However it's true that there are a lot of systems out there which instead give you a password for first login (or worse they have a fixed default!) which is sad.

B. The server has existing users, but not me. If we're not using certificates then I need an existing user to authorise me to use the machine, providing public keys is no different than anything else they might fill out, like my name, they will need a trustworthy source for all of it. For systems I have no other prior relationship to beyond that I am, as you see, tialaramex, I tell them to add the github keys for tialaramex, which are of course published. I will replace those after successfully connecting to their SSH server.

C. I've used this server but not from this machine. FIDO resident keys solve this (you can extract the resident key to a new client from your physical device, the device still needs to be present to actually authenticate) but I will also use SSH to connect to my home bastion and have that authenticate while I do setup once. I can SSH from my phone, so if this can't work then somehow I don't have my phone or access to my home, setting up SSH keys is a low priority in that case.

However it's true that none of this is yet ordinary.

When you install Ubuntu it asks you for your Github username and pulls your public key from there, making having the corresponding private key the only way to log into the system.

If you lose all your key material, then I wouldn't expect for you to ever be able to log into the system. Passwords have the same problem; if there's some machine you can only remotely connect to and you forget your password, you simply won't be accessing that computer anymore.

Keep following your own logic. If you don't have a preexisting key relationship and you can't trust the network, are passwords safe? [Y/N]

If you cannot trust the network, where is the advantage of keypairs over passwords?

If you have a one-time password, worse case is that some man in the middle gets that password.

If you engage in a proof of private key ownership for your login, a man in the middle can use that exchange to log into another server that has the same public key.

First, if you use an SSH CA, you don't necessarily have the first-use problem at all; that's part of the point of SSH CAs. You've resolved that problem the same way TLS does.

Second, an attacker targeting your keypair-backed SSH session on an insecure first-use gets your session; against a password, they get your password, which is strictly worse.

It's not my claim that keypairs neatly solve the first-use problem with SSH (though: that problem can be solved, with more keypairs). It's that keys are categorically better than passwords. Which, of course, they are.

The alarming thing about this thread is that there's a couple people here that clearly seem to believe logging in with a password to a "new" SSH server is safe. It's literally the basis for the "Wall of Sheep" at hacker conferences; they were doing it at Usenix when I was there in 1998.

> If you engage in a proof of private key ownership for your login, a man in the middle can use that exchange to log into another server that has the same public key.

No, this is not true. The proof of private key ownership is bound to that specific SSH session (identified by some shared secret established via DH). This means the attackers options are: MITM the DH: Then your authentication won't work against any server. Don't MITM the DH but forward your authentication to the wrong server: Then you're on the wrong server (you might not notice), but the attacker cannot look into your session or modify anything.

He can do it once, maybe, if you don't authenticate the server. With a password, he can do it any number of time, to any number of targets, and there's no way to catch it.

Yes, it is still not perfect, but here's the advantage.

> and you can't trust the network

Why is this a requirement? Not having a configured machine does not imply an untrusted network. Maybe all my computers recently and unexpectedly got wiped and I'm trying to rebuild my home network.

Repeat exercise, but with untrusted computer. [Y/N]

If you trust literally every component involved in the exchange, is rsh safe? [Y/N]

Depends on how the server was setup. Ubuntu has offered importing public keys from github for quite a while in its installer. If you're using terraform/ansible/some other IaC tool, adding a key is probably just 1-2 lines of code. Some OS, like Guix or NixOS, also allow you to define them in a config file. Worst case you can just do something like `curl -L github.com/username.keys >> .ssh/authorized_keys`.

This is also part of the reason big fleet operators like SSH CAs, since they work for host keys and solve the key continuity problem.

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?

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.

I understand what you are saying but in my experience the opposite can be equally true. Unless every system in your org is managing the authorized_keys for every account with automation and hourly validation one can end up with rogue keys, forgotten keys, unmanaged keys. SSH has no concept of identity in this regard. If I temporarily have sudo on a system I can append any random public key into the authorized_keys of any account. It gets even worse if that system allows passwordless sudo. Now there is an audit trail that showed you made a reckless change when it was really me. This risk gets exponentially worse if the system I append a random key into is a command and control or configuration management system. One doesn't even really need sudo for this to be a problem given how much power non root accounts have over applications, deployments, builds and secret management.

Is authorized keys important here? If I send the server my password, it has my password. If I send a server my public key, that's a lot less severe. If an attacker is on the server I expect that the difference is obvious?

Both are vulnerable to phishing via malicious scripts. One could even argue that keys are more dangerous if the attacker can append their own key into authorized_keys one host at a time. Some might be surprised how incredibly easy it is to get a percentage of technical people on an email distribution to execute a script without fully understanding it and this is even leaving things out like compromising npm repositories. Said script can drop a key into authorized_keys or drop a custom key and create an outbound session invoking a gateway port allowing the attack to ssh to the host even if they have no inbound ports open. From there one can repeat the process as access is gained first at the workstation or laptop, then the jump host then build servers, repository servers, staging servers and ultimately production servers.

SSH is a power communications tool. It is equally powerful to both the authorized user and to attackers in my experience. It is often poorly managed if even managed at all even in the most sensitive environments in some of the most high profile organizations.

How would you phish my private key?

I would not. I would phish you running a script that adds my public key to your authorized_keys and would ssh from your client in the background creating a gateway port back to you. At that point I can get your ssh keys and just about anything else. If systems in your org allow ssh multiplexing default is enabled then I can also piggy-back your sessions bypassing MFA/2FA.

I say you but I mean most people. I'm certain that you specifically would not fall for it but about 10% [1] of technical people will.

[1] - stats based on past career and testing of a large technical population.

I'm not sure I understand the attack. I connect to a server that you, the attacker, are on. How does your attack get my private key? Assuming I'm not forwarding my key, and you're not on my laptop.

You run a script that has obfuscated code. The script is "broken" and has an easy problem for you to identify for me. You feel good about finding my amateur mistake.

In the background the script has dropped my public ssh key either into your authorized_keys if you have sshd running, or into a random location if you do not and launches sshd as you in the background if it is not running. It can be on a high random port listening on 127.0.0.1, this is fine.

The script also backgrounds an outbound connection to a machine I control enabling a gateway port that I can use to SSH back to your machine even if you are behind a firewall. It will tell me if you have ssh listening on 22 or on the loopback and what port. My tunneled ssh connection will utilize that ssh key I appended or dropped. I am not on your machine as you. That back-grounded connection can also be added to your .[a-z]* shell login files based on the shell you are using at the time so that if you reboot the tunnel is recreated.

Now I am on your machine as you and I can grab your private keys, ride along your existing SSH channels that you have authenticated with your 2FA/MFA provider assuming the hosts you connect to leave multiplexing enabled, connect to your browser and watch the console http session data and so much more.

This scenario will technically work on most peoples setup. About 10% of people will run the script. No hacker tools or malware required, just an obfuscated script. This will never be detected by anti-malware software. The script language will depend on what I think your organization uses. It could be python, perl, ruby, go, java, bash, anything really.

The only technical mitigating control would be to limit where the person can make an outbound connection. i.e. pre-approve TCP destinations. If a laptop or workstation can SSH to a random cloud provider then the script will work.

You're not on my machine. You're on the server. You still don't have my private key.

What I described above puts me on your machine. This is not theory, it has been tested against many people. Legally of course.

So you were vague about where I execute the script. If I execute the script on my client, obviously you have my key, but that's not interesting. If I execute the script on my server, you do not have my private key, period.

This whole "I can ssh back to your machine past your firewall" is not a thing I understand, I am not aware of that capability in SSH.

I've received the private component attached via email before. People find a way to mess up.

re-using an insecure key is just as easy https://github.com/mikalv/anything2ed25519