Don't know what the grandparent meant by GSSAPI, that is just an API for various underlying auth methods. But what people usually use together with GSSAPI is Kerberos.
Kerberos can be very secure, much more so than CA-based or generally asymmetric crypto based approaches. Kerberos (if you ignore some extensions) uses symmetric cryptography, so it is less vulnerable to quantum computers. Use AES256 and you are fine, a quantum attacker can at the most degrade this to a 128bit level (according to current theories). Also, no weak RSA exponents, elliptic curve points at zero, variable-time implementations or other common pitfalls of asymmetric crypto. The trusted third party ("KDC" in Kerberos) distributes keys ("tickets") for pairs of user and service-on-server, so mutual authentication is always assured, not like in ssh or https where you can just ignore that pesky certificate or hostkey error. Keys are short-lived (hours to weeks usually), but there are builtin mechanisms for autorenew if desired. Each side of a key can also be bound to a host identity, so stealing tickets (like cookies in HTTP) can be made harder (but not impossible). The KDC can (theoretically, rarely implemented) also enforce authorisation by preventing users from obtaining tickets for services they are not authorized to use (the original idea of Kerberos was to just use it for authentication, the authorisation step is done by the service after authentication has been established).
Single-Sign-On with all the usual protocols is included automatically, you log in to your workstation and get a ticket-granting-ticket that can then be used to transparently get all the subsequent tickets for services you are using. The hardest one to implement is actually HTTP, because browsers suck and just implement the bare minimum.
However, the whole of Kerberos implementations is ancient, 1990s era software, packed with extensions upon extensions. You don't really want to expose a KDC to the open internet nowadays. The whole thing needs a redesign and rewrite in something safer than 1990s era C.
Oh, and there are mechanisms for federation like trust relationsships between realms and KDCs, but nobody uses those beyond merging internal corporate networks.
the weak point of Kerberos is not the Kerberos protocol itself, but the most popular implementation of it being Microsoft Active Directory.
Due to an incredible bloat of AD and entire Windows/Azure ecosystem, it has an enormous attack surface (multiply the universe of all windows ecosystem by the decades of old versions being supported for compatibility), and any vulnerability in the ecosystem (past and present) can lead to escalation and compromise of the Active Directory itself.
so is Kerberos secure? as a protocol it is fine, cause it was developed at MIT by smart people.
is MSFT AD/Windows ecosystem secure? HELL NO, stay away
Well, yes, almost totally in agreement, but: MIT Kerberos (the implementation) started out as "research-quality" code of the 1990s era. It has improved, it fares far better than AD, but the occasional exploits still continue to drop.
Doesn’t this require the server to consult the IDP on every log in, though, to make sure the id token is valid? One of the staples of ssh from a UX standpoint is that it’s peer to peer.
the difference is in /key management/. Key management is the hard part. Especially keyless SSH management. (things like sigstore's rekor/fulcio remove some complexity here). It is not "just a (manually generated) ssh certificate"
Having worked as Cloud Solution Architect at Microsoft Germany/Azure, let me tell you:
Nope this gap can not be closed by any US company alone due to the Us Patriot Act - which forces any US company (including e.g. a German subsidiary) to allow access to all data for national security purposes.
Having worked at AWS, no, it's a separate partition under a separate legal entity, and the EU framework is specifically designed to counter Patriot Act, CLOUD Act and the like. It's gonna be similar to AWS China, and potentially more restrictive in some senses. That leaving aside regions we're not allowed to talk about.
> This should be disclaimer at your first message when you compared AWS with UPCloud.
Fair, my bad. Still obviously misleading.
1. DB instances "starting at $144", I have a $63 in my basket at the moment, and also Aurora Serverless charges on resources used and can be potentially cheaper depending on the workload.
2. "$82.8 /mo" for a 2 core 8GB server is actually just under 50.
3. European DC locations: 8 for both. Unsure what UpCloud means for them here[0], they look like actual, individual DCs, but AWS has 8 European regions. Each region has normally 3 AZs which are physically separate DCs (which can be in proximity or not) and can be composed of multiple DCs each. Plus there are localzones depending from certain regions, each with at least one DC (and there are 11 of those). So the AWS number is certainly over 30 if we compare apples to apples.
The rest I don't have time to dive in, or are just opinions (certifications needed for proficiency? really?)
>TBH, I would not trust AWS with countering the Patriot Act.
AWS China wouldn't have happened if they didn't offer enough safeguards. Complying with Patriot Act will guarantee enormous fines for AWS in the EU, so I'm sure legal and finance did their homework for AWS not to end up between a rock and a hard place.
> AWS China wouldn't have happened if they didn't offer enough safeguards.
AWS China vs. AWS EU: Data centers in China are managed by Chinese companies, whereas DCs in the EU are managed by USA companies.
From a regulatory perspective, it's two different worlds. The Patriot Act can happen in the EU, not in China.
This is why GDPR does allow that EU user data is transferred to non-EU countries, but not to the USA.[0]
Furthermore, a discernible trend has emerged, attributable to the inadequacies in privacy regulations and suboptimal Trump geopolitical strategies with the EU, the EU is actively seeking better cloud services [1].
GSSAPI can be more secured than public/private key if configured right.