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