webvictim

I almost cannot believe the actual cause. Absolutely awful experience.

The overarching reason isn't really a question of "helping users" as such, although I would strongly encourage making the certificate issuing process as quick and easy as possible to encourage adoption and reduce pushback. The people it really helps are security teams and organisations as a whole who can now have more confidence that they haven't left holes in their infrastructure which can be exploited by bad actors. It also checks a lot of boxes for auditing, compliance and reporting purposes which are huge positives in a corporate environment. If you're able to say "yes, disgruntled former employee X had a certificate that would have given them access to all these servers, but it expired three days ago" then that's a lot better than saying "X has a certificate that gives them access to all our servers, but we _think_ we've blocked it from being used everywhere".

Overall, I agree that the model does lend itself better to things like access to critical production infrastructure (where access should be the exception rather than the rule), but in my opinion it's a good practice to get into for access to everything. The ability to log that a certain user requested a certificate at a certain time and then link that to exactly where the certificate was used (via centralised logging, for example) is incredibly powerful.

You're perhaps correct that both do constitute fail-open systems at first. The difference is in the vulnerability period - with an expiring certificate, that ends at a fixed point in the future. With a certificate that has no expiry, that period never ends until such time as you rotate your CA and force everyone to get a new certificate - something which is also far less of a burden when your certificates expire every day by default and you have a process for getting a new one, incidentally.

Look at it in terms of building in a decision at compile-time rather than at runtime. With AuthorizedKeysCommand, you're running something just-in-time on an SSH login to determine whether something should be allowed to proceed. With a CA and a process for issuing certificates, that decision is made at the time the cert is issued and then the cert is good for the duration it's issued for. It's entirely self-contained as sshd itself is making the decision about whether the cert is within its validity period or not.

It's obviously a decision that people can make based on their own infrastructure, but my opinion is that the compile-time model is more reliable as it's a fully self-contained system and doesn't rely on an entire fleet of servers being able to connect back to an external service at runtime to determine whether you should be allowed to log in. That sort of thing invariably comes back to bite you when you really _need_ to be able to log in and you can't because the external service is down.

If you have a certificate which expires within a day by default then an unsuccessful revocation is no longer a huge cause of stress. In the worst case, you lock down access to your bastions and disallow the issue of any future certificates for that user. Within a day, any potential threat from that certificate has vanished. This seems preferable to having a mandatory requirement of an up-to-date revocation database which is synced everywhere.

Certificates can do a lot more than authorized keys can, like enforcing the use of specific principals, commands and options and embedding that information into the file itself without needing to modify each server's SSH configuration. They're also self-contained and will still work in situations where some external service providing a list of keys goes down. I've been on the rough side of a huge LDAP outage which prevented necessary access to the infrastructure to fix it, and it was a horrible experience. There's none of that problem with certificates as long as you make sure you have one which is currently valid.

I'm also generally of the opinion that it's safer to enforce the use of authentication which expires by default rather than relying on some external process to do that for you.

I'm considering doing a future post on how to set up U2F for SSH with hardware devices (like a Yubikey) as well. I'm curious if you have anything else you'd like to see on this topic.

I found some other resources/projects online while I was writing this which indicated that I certainly wasn't the first interviewee to be asked to do this - I evidently wasn't the last either as your project shows.

My point is that it seems Gravitational has had this 'idea' for quite some time as they've been using it as an interview question for at least the year 2018. I don't feel like that constitutes them using anyone's interview work as free labour.

https://www.glassdoor.com/Salary/Google-Salaries-E9079.htm

It seems similar to the way it was at Facebook in that when you start, you'll be assigned a level based on your previous experience and it'll be corrected soon afterwards if it turns out to have been wrong. They mostly corrected up, though - it was very rare for someone to be assigned a high level and then downgraded afterwards.

Obviously the Glassdoor link shows that there is a pretty big range in the salary bands - I think some of this is down to people reporting total target compensation (including RSUs, bonuses etc) versus base salary but there was a fairly large range at FB too. It wasn't uncommon to stay at the same level but have your base salary go up by $20-25k.

I was born at the end of 1984 and played games on it with him from around age 3, then started tinkering myself and learning how to load games and play them at around age 5. In another couple of years I was going to the library and checking out books full of lengthy game listings in BASIC, painstakingly typing them in, running them and saving them to tape. That experience basically ignited my love for computers and for programming. When the family managed to get a cheap PC I was about 9 or 10 and I spent as much time on there as I could, learning how to use MS-DOS 5, Windows 3.1 and playing games.

After this point I scrounged whatever hardware I could - I acquired an old IBM 286 with an EGA monitor that a local school wanted to get rid of, various other components, borrowed software off friends to copy the disks, etc. My parents were pretty supportive and at age 13 they were a little better off - I persuaded them to get me my own PC as a joint birthday and Christmas present, using an old monitor and peripherals we already had. I got access to the internet and started viewing the source of web pages, copying the HTML, learning what it did and editing it to make my own pages. I started to learn CSS, how to edit images and how to write Perl.

The story goes on and on - I'm mostly just going on a bit of a ramble about my past and fondly remembering all the experiences I had. The point is that yes, if your family is absolutely on the breadline while you're growing up then you probably won't have access to this stuff, but we were by no means upper middle class and I managed to get a great start with computing. It's mostly about passion and people looking out for you. I scrounged so much old hardware and software from people who didn't want it any more because I knew it'd be a fantastic learning experience, and I was lucky enough to have parents who encouraged me to do this and didn't spend the _entire_ summer telling me to go outside and "do something".

I'm not saying he's autistic, but he has the same temperament and characteristics as people who have mild Aspergers - essentially what the OP said.

I was also always hugely jealous of people in war rooms as they seemed to have the perfect balance.

A colleague put in a facilities ticket on the morning of the second day we were there to get the table relocated. Facilities couldn't find anywhere else to put it (because it would've meant simply disrupting someone else's area) and so the table was removed and put into storage. This caused a huge outcry from the ping pong players, but did have the upside of allowing us as developers to do our jobs.

I saw the whole situation as quite ridiculous, given that we were all at work in a company office and getting paid to code rather than to play ping pong. The counter-argument was that the removal of a ping pong table was the thin end of the wedge and the sign that FB was slowly becoming corporate and losing its hacker soul. I guess I can see the point, but the reality is that ping pong is a brilliant game until you have to sit near the table and try to work.

The headphones are very reasonable for what they do (and of course, they're free to you, so even better) but in terms of actual noise cancelling you'd have to buy your own. Of course, FB pays developers well so spending $300 on a set of Bose QCs is no problem at all, but a lot of people don't bother or see the point when there are free sets in the vending machines.

The worst thing of all (in my opinion) is the fact that the open office culture is simply accepted there as being the best thing for all concerned. It's like a theory that cannot be challenged. The introverts basically don't get listened to, while the extroverts can sing and dance with happiness. This surprised me greatly because anyone who's worked at FB will tell you that it's a hugely data-driven company - lots of people did try a great many times to suggest that we should trial team-sized offices or at least something different to the status quo, even providing studies and statistics to back up their hypotheses, but the requests always fell on deaf ears. I'm not sure it was ever taken seriously as a concern despite numerous articles like this being linked internally and debated ad infinitum. It's a real shame, as the company was a pretty great place to work on most other levels.