Hacker News Reader

Comment by themoonisachees | Hacker News Reader

At my previous job, we had an entire system aptly named Pandora whose entire role was keeping track of which ssh keys were permitted to be found on servers. It had a bot that would crawl through every server, and if it found a key not in it's database, it nuked it. Every new person or automation key had to first be registered fomarlly, with an end date. A bit of a hassle but definitely necessary for the space the company was in.

View on HN

That’s a good idea although I’d probably be paranoid enough to have a human do the deletions, out of fear of the failure mode where it deletes all the keys everywhere and nobody can log into anything.

There is a future where they're locked out of the servers.

Why not use ssh certificates at that point?

I assume op’s system was to allow A to ssh to B, but not to C. (With lot of different As and Cs)

Where “but not to C” is the reason for existence.

How certificates simplify that part?

(Never used them, but my understanding they are usefull when you want x1,x2,… ssh’ing into y1,y2,…; two uniform sets; if set sizes approach 1, then cert usefullness aproach zero)

I would have been a good use case, but unfortunately no, if your key was registered it would be left alone on all servers (though you had to place it, and access control was done by way of bastions).

Ssh certs weren't used because the system was put in place before they became commonplace.

Reply on news.ycombinator.com