Okay.. I just did it. I had to reinitialize a server because I lost the single SSH keypair (probably the one from my BELOVED Windoze desktop that I recently had to reinstall) that was authorized to access the server, and I didn't add any of the other clients' keys to the server's authorized_keys.

Note to self: replicate all your fucking keys or (or rather, and) back them the fuck up into your keychain already!! Why else does that keychain USB stick exist, Condor, you bloody fucking moron?!!

Well, at least now the admin panel on Aruba Cloud doesn't say "Ubuntu 14.04" that's been upgraded to Ubuntu 18.04 anymore, but 18.04 as it should.. but that's about the only good thing.

One word... Yubikey..... The yubikey 4 and 5 support 4096 gpg certs. Create the cert on the device or move it to the yubikey. You have to create a derivative SSH public key from the gpg key, but it works like a champ. It also has a pin, so you with once and are ready to go until you unplug it. It also doubles as a git commit signing key.

@xJvf link to configuration guide... https://developers.yubico.com/PGP/...

@xJvf Or just use the gpg ssh agent and cut out the need to convert the key

@PerfectAsshole You will use the gpg-agent, and you still have to create a public SSH key for the remote server.

@xJvf ssh-copy-id

Been there so many times. Those days suck.

Why don't people use root passwords as a recovery mechanism...?

@netikras for security reasons, you should only allow root passwords to authenticate at the physical terminal, not remotely. For cloud devices, that's kinda hard.

@taigrr allright, what are the chances to guess a

dd if=/dev/urandom bs=1 count=1028 2>&- | sha512sum

root password?

I do have a root pw set on my servers for years. With 10-20k of login attempts per day. Considering they are all probably using dict attacks I do not feel threated at all. And if I lose my ssh key I still can recover w/o losing any of my data

@netikras Sure there are clever things you can do.
General knowledge dictates you should disable remote password login for root. There's specialized knowledge, which tacks on the exemptions, if you know what you're doing. I always make sure I have three ways into a system, and I use yubikeys for everything (I have 3, all loaded with the same credentials. One with my car keys, one in my desktop (the room stays locked), one in a safe.) The keyfiles are encrypted and stored safely as well, with a password and airgapped, should I need to recover them.
The issue now is, how safely is your root password stored? That's probably your weak link.
As to the math behind "what are the chances" for a brute-force attack? You're probably fine. But you know that, because you're asking.
I personally have disabled root login. Sure I could limit it to an IP whitelist, or limit it to an ssh key, but I disabled it completely. I'd rather have a memorable (diceware) root password for those times I need to su.

@taigrr storing your root ssh keys and storing your root password - I don't see a difference. I use my ssh keys for a BAU. Don't even bother backing it up. Root pw is stored on a device not accessible from the internet (okay, it's accessible. but in a very speciffic way), on the other side of the country.

I can easily lose one auth token (key/pw) but it's very unlikely I'll lose them both without any time left to recover either.

I do consider this a safe approach. Cracking or finding the pw is more than unlikely.

@netikras Sure, I agree there's probably no real difference in storing a root pw vs key, *except* that you can allow root login via key and not via pw, so that even if you expose the pw, you can still assume you have a fair bit of time to log in and change the pw with the ssh key. The reverse isn't true.

@netikras the security behind that should be reasonably good, but it's just that I don't feel comfortable with the idea that someone *might* be able to crack the password when given enough time, as opposed to the reassurance of knowing that password authentication will never work..