5 ms·
Nope! Ed25519 is great and honestly I think the compatibility concerns are overblown. It was introduced in 2014. If you are running four year old SSH you have o
by lvh 8y ago
Nope! Ed25519 is great and honestly I think the compatibility concerns are overblown. It was introduced in 2014. If you are running four year old SSH you have other problems, like probably RHEL or some nonsense.
That said: Ed25519 is a local optimum: the bigger win is to not have long-held credentials at all, and instead use an SSH CA or something like Gravitational Teleport. Doesn't work for GitHub though.
- jakobdabo 8y agoRHEL 7 (and derivatives) do support Ed25519 keys.
- glenjamin 8y agoIn a world where you don’t have long held credentials - how do you get the short term credentials?
- guelo 8y agoYou could have a key rotation process where you use the old key to install the new key and delete the old key. But it seems sketchy because if you don't rotate in time the old key expires and you're locked out. I think in practice you'll always end up with a super-duper secret, rarely used, long term key. Or have some other backdoor like root password, LDAP/Kerberos, ADFS, etc.
- cbhl 8y agoIf I understand correctly: with long-held credentials. Basically, you use long-held credentials to generate short-term credentials, and then use the short-term credentials themselves to access whatever server or service you need.
- deleted 8y ago[deleted]
- xyzzy123 8y agoWe do this: Master user records in an identity/SSO system. We use ADFS. Use a protocol which provides a portable “signed”, temporary credential. We use SAML but OIDC also works. Have a command-line client which auths to the SSO and then relays an identity proof to a trusted component (lambda, cloud function, dedicated instance, whatever your policy says is ok). The identity proof is just a saml assertion or oidc token. Have trusted component validate the identity proof from SSO and generate time limited credentials (we issue ssh, kube and iam). Our client then auto-xfers those creds up to jumpbox but you could drop them on workstation instead if your policy allows.
- tptacek 8y agoThis is roughly what I'm talking about when I bring up SSH CA short-lived credential workflows.
- wvh 8y agoI currently work in academic environments and I don't have much faith in the SSO systems. I thought about this, but often the SSO credentials are also the email password – the one password that gets entered and stored just about everywhere for the average user. I'm not willing to bet the security on a user's main login/email password, which seems to be a common setup. With that password or even just access to a user's main mailbox, a smart attacker might get through multiple layers of security by simply convincing services or staff to reset credentials. Though it might work with a second, more limited (not-so-)SSO system for specific users and environments.
- lvh 8y agoYou're right that shitty systems train users to be phishable -- by typing their password all over the place -- all the time, not even counting the poor default password hygiene most users have. This is one of the reasons U2F/WebAuthn is so incredibly valuable.
- amaccuish 8y agoI love SAML (not the XML part), it gives me one place where I can concentrate. My SSO first tries kerberos (if they've logged into their Windows machine using AD), x509 for smartcards, and if all that fails, username+password+totp. Password login is blocked without a TOTP token provisioned. Also it's one place I can stick fail2ban rules.