As for access if you lose a key, unless you somehow run a VPS that also uses full-disk encryption (and requires a passphrase on boot), then your hosting provider has access to your VPS.

For instance, with DO or Linode, you can log in to the admin console and reset the root password of a server. Once done, you can use the terminal built into the admin panel to access to the server even if SSH is disabled.

Presumably, someone could work with the provider, prove you are dead, and that they should gain access to your servers. At that point it would come down to the policy of the hosting provider.

The disk encryption doesn't buy you much in such an environment, though... Even with whole disk encryption if you're running virtualized; then your provider can just read your VM's memory anyway...

Unless your VPS is going to be forever shutdown, disk encryption under a hypervisor you don't control seems reasonably pointless -- I only use it for physical security to stop people being able to use disks they yank from physical boxes -- even then if they were motivated enough they could probably grab the memory from the server(s) and get the keys anyhow...

AFAIK, there is no possible protection from this besides running your own gear. There were recently published attacks where someone managed to pull keys from other machines by abusing some either intel or vmware's memory dedupe tech bugs iirc (don't have the link handy) -- so; it's not even limited to what your provider may be doing...

Edit:

To elaborate on this a bit more -- perhaps I'm not an ideal role model for 'best practice' ssh key behavior -- but I end up dealing with a whole load of keys and boxes in $dayjob:

punkz:~$ wc -l ~/.ssh/known_hosts

1473 /home/punkz/.ssh/known_hosts

punkz:~$ ls -l ~/.ssh/id_* | wc -l

31

I deal with these by creating a new keypair for each client I'm working with (sometimes one for each of their environments) and I incorporate their name, or the location of the office I first attended for them, into the passphrase for the key somehow. While this is similar enough to the others that I won't forget the whole thing and so if I have to pick up some old client where I've forgotten the phrase there's usually only about 4 combos with the client's name or the address with various CaSeOpTiOnS or so on that I can usually get there..

I suspect if someone, or ... say .. some state, was targeting me personally to get access to a specific key that if they've gotten to the point where they have copies of them anyway; I wouldn't be able to stop them with a clever passphrase which is more unique than what I currently do.. Thinking along those lines then, I'm aiming to protect against lazy/stupid attackers wanting 'low hanging fruit' as it were, vs the big boys who probably have other ways of pulling these secrets from me....

I maintain a completely different passphrase schema for my personal keys -- either way, that's how I do it; seems good enough for me.. Any thoughts?

Or say, someone pwning a dev jenkins box doesn't get an agent connection which lets them into prod...

Look at ssh's -W or -J options (depending on how old your ssh client is), or see e.g. [0].

[0] https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Proxies_and_J...

I really must have missed the story here -- people pay for a third party service to manage their private keys?

... Err. That's so illogical it's making my brain hurt to even work out why I would need to explain how illogical it is...

I can't even come up with a good analogy for how wrong that whole idea is, fortunately I don't have to though since no one that has mastered 'ssh-keygen' and 'cp' would actually do so.....

2FA, okay; the service provider only has half the story. ssh-keys-as-a-service? WAT.

Edit:

Okay, I looked a bit more at userify and it seems to be an agent that runs on your systems which generates authorized_keys files....

From their docs:

"There are two parts of the Userify installation: creating the agent (readable only by root) in /opt/userify, and setting the agent to start at bootup. Setting the agent to start at bootup is a bit trickier, but the installation process attempts to detect the server type and set it up properly."

Am I reading this wrong? You hook up an agent, which runs as root, which farms out authorized_keys entries across the estate? One possible mech for deploying the agent is conf management?

What the actual fuck? Why would anyone do this? Do I even need to explain why this is blowing my mind so much?

I'm not saying it's a good solution though. I agree that it's giving someone full access to your whole environment and it's a bad idea.

Okay, there are a few things here.. I'm not trying to rant at the people behind this directly, there are a number of similar agent-based tools which have similar issues, so please don't take it personally...

1) If you have the ability to roll out an agent such as this, with your conf management, then you could just manage your users that way instead....

2) Even assuming that this SAAS is un-hackable (lolz), you're now in the situation where all access to every machine in your environment can be changed with a single password on some web ui you don't control, which can be accessed from anywhere.

3) This should go without saying -- I can't put too much faith in how well it's implemented -- pwn the saas, then I immediately own every system connected to it..

4) The enterprise docs talk about sitting it next to your LDAP system... If I had an ops discipline and environment which has gotten to the point where I'm dealin with LDAP, why wouldn't I just configure PAM to read my ssh keys from that, instead of this?

I understand this is one of many such products which are coming out of the lack of desire/time/staff to handle opsy-style tasks when features could be getting written (I'm planning a talk on this...)

But.. does anyone really think that the cost of spending a day wrangling ansible to manage access to your servers is worth more than giving some random third party the ability to add users to your production databases?

I've dealt with many, many different auth mechanisms up to this point. LDAP+Pam_MkHomedir, NFS, Config Management, Shared Keys, Shared Passwords, etc etc. Each have problems, but I don't think the issues with any of those are solved by this, are they?

This must be aimed solely at small startups with no ops experience, right? No one would actually put this near real data, would they?

I hope so. But if I'm wrong, I'd like to hear from the actual users what do they get out of it.

Also, you're probably running servers at a third party hypervisor already.. ;) they could be scanning your RAM and reading your disk and you'd never know.

I certainly wasn't trying to shit on you (or your company/employer) personally... but to me the idea of turning over ultimate control of all my servers, data, etc., to some unknown third-party and simply trusting them is absolutely fucking absurd.

I pretty much agree with everything cyberpunk said in this thread. I've been around long enough that it shouldn't but some of the things people do with regard to security sometimes surprises me and just leaves me standing there with my mouth hanging open, saying "WTF?".

So how do you feel about TLS and the 100's of trusted certificates embedded in your browser/mobile device?

... eh?

EDIT: Case in point.. did you know the name WoSign before they became notorious? https://docs.google.com/document/d/1C6BlmbeQfn4a9zydVi2UvjBG...