I genuinely thought the same thing. I opened my MBP and it was sluggish, felt like it was dead. Browser wouldn't load, Zoom wouldn't load, I rebooted and the same problems persisted. I honestly thought the hardware was giving out.
I almost cannot believe the actual cause. Absolutely awful experience.
Setting all of that infrastructure up and subsequently maintaining it involves a considerable amount of time and knowledge. Some people just want a solution that's easy to deploy and that handles all of the management for you.
Yes, even for very regular users I would recommend setting up a process requiring users to get a new certificate on a daily basis with a short validity period. You can automate a lot of this and make it a simple one-command process to get a new certificate - even something like a simple shell script called by ProxyCommand is a good habit to get into. In bigger organisations you'd likely want to centralise this process somehow or institute other tooling.
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.
It's something of an implementation detail - you don't generally specify the usage of certs on a user-by-user level, you do it by trusting the entire CA in /etc/ssh/sshd_config and then using the signed content of the individual cert (expiry date, principals etc) to dictate whether someone should be allowed to get access or not.
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.
Author here. My take on this is that fail-closed is a vastly better security model than fail-open. I am genuinely surprised that OpenSSH actually issues certificates with no expiry date as a default.
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.
Author here - yes, this is why. I looked into Ed25519 and while there are a lot of great reasons to use it (such as a shorter key footprint and it being much quicker on mobile devices), RSA is still more widely supported and has more documentation/examples available. ECDSA was an option too but doesn't provide the same benefits as Ed25519 would.
Don't get me wrong, using AuthorizedKeysCommand is a lot better than having a static ~/.ssh/authorized_keys file on a server, but it isn't anything like as powerful as using user certificates.
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.
This is definitely the premise of what I was going for with the post. I'm a firm believer in the idea that short-lived certificates which expire by default are one of the best ways to provide access to infrastructure, and enforcing that access comes from a limited list of bastions gives you an easy choke point to withdraw access as desired when you need to.
Author here - thanks for the feedback. As another reply points out, I did try to also cover the use of a bastion host along with one form of 2-factor authentication.
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.
Author here. If you specify an IdentityFile then that’ll be tried first (as an explicit identity) but if that doesn’t work then by default, ssh-agent identities will be tried sequentially afterwards. IdentitiesOnly suppresses that behaviour.
Maybe banners, artwork, bio, follow relevant accounts, make some starter tweets with popular hashtags to get some follows back, interaction with some key people. I wouldn’t pay for it personally but someone might.
FYI, I was hired by Gravitational back in April 2018 and I was given that same take-home assignment as part of the interview process - to write a CNI plugin for k8s which created an encrypted mesh network between nodes. My work is here: https://github.com/webvictim/k8s-ipsec-cni
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.
The drain on the systems in Europe from those who are “gaming the system” and who are long term sick pales into insignificance when you consider the overall savings due to the collective bargaining power of a nationalised healthcare system.
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.
My family weren't at all well off when I was growing up in the UK, but my Dad had some contacts in a local IT business who had a spare BBC microcomputer that he got hold of around 1988 when they were throwing it away.
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".
Watch some early videos of Zuck and it'll be much more obvious. He's had a lot of training in public speaking and engagement and he's a ton better than he used to be now.
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 almost cannot believe the actual cause. Absolutely awful experience.