We added SSH certificates support to pico.sh [1] and it's been great. Utilizing principals gave us the ability to implement a RBAC like system for specific parts of the pico.sh ecosystem. Users get the flexibility they want with limited complexity.
SSH certificates: the better SSH experience
101–110 of 137 posts
Re: SSH certificates: the better SSH experience
#102Sadly services such as Github don't support these so it's mostly good for internal infrastructure.
They do, for Enterprise customers only: https://docs.github.com/en/enterprise-cloud@latest/organizat... They've rolled their host key one time, so there's little reason for them to use it on the host side.
I’d love if they supported an SSH certificate CA for commit signing verification though.
Re: SSH certificates: the better SSH experience
#103Earlier quoted context omitted.
> Also, I've never had a security issue due to TOFU, have you? This is a bit like suggesting you've never been in a car crash, so seat belts must not be worth considering. Do you feel that beyond the obvious and documented work in setting them up, there are disadvantages to using SSH certificates?
Certificates provide extra features, like revocation. However, if you do not need the extra features provided by certificates, using SSH-generated keys is strictly equivalent with using certificates and it requires less work. TOFU is neither necessary nor recommended, it is just a convenience feature, to be used when security may be lax. The secure way to use SSH is to never use TOFU but to pair the user and the serv…
> secure channel, e.g. either by using a USB memory
Aside: We need a "safely dumb" storage plug standard. Right now the flexibility of USB is a double-edged sword, any USB device could potentially be malicious, waiting for the right moment to send keystrokes as a keyboard etc.
Or use the same plug for everything, but support a "passive storage only" that can be enforced by a special adapter or cable.
Re: SSH certificates: the better SSH experience
#104The experience might be better right up until you're running it in prod and someone happens to ask about: Cert revocation (or even expiration) Sudo roles User removal and process termination Is the cert server HA and locked down How you log in when the cert server is down or under attack (rich target!) How to easily add Alice to server group A, Bob to B, and Carlos to both A and B, and then to remove them.. (disclaim…
Sorry to pop your bubble, but a SaaS is the worst possible option.
Then install your own:
curl i.userify.com | sudo - sERe: SSH certificates: the better SSH experience
#105Earlier quoted context omitted.
A big problem I have with ssh carts is that they are not universally supported. For me, there is always some device or daemon (for example tinyssh in the initramfs of my gaming pc so that I can unlock it remotely) that only works with “plain old ssh keys”. And if I have to distribute and sync my keys onto a few hosts anyway, it takes away the benefits.
Might actually be a positive instead of a negative. Gaming use-cases should have not any effect on security policies, these should be as separate as possible, different auth mechanisms for your gaming stuff and your professional stuff ensures nothing gets mixed.
remote unlock is also useful when you're not gaming so that feels like the wrong aspect to focus on
Re: SSH certificates: the better SSH experience
#106Earlier quoted context omitted.
I am keeping an eye on the new (and alpha) Authentik agent which will allow idp based ssh logins. There's also SSSD already supported but it requires glibc (due to needing NSS) meaning it's not available on Alpine.
If you mean using OIDC, in that space there's at least https://github.com/EOSC-synergy/ssh-oidc , https://dianagudu.github.io/mccli/ and OpenPubkey-ssh discussed in https://news.ycombinator.com/item?id=43470906 (which might mention more). How does SSSD support help with SSH authN? I know you can now get Kerberos tickets from FreeIPA using OIDC(?), but I forget if SSSD is involved.
Can't really speak to the point of the guy you're replying to, but the FreeIPA implementation via SSSD does more than just Kerberos tickets. Actually, I think the Kerberos based stuff as it relates to SSH is GSSAPI as part of sshd itself and has little to do with sssd, though I could be wrong.
That said...
If I'm remembering things correctly (and it's been a looong while since I've played with this), FreeIPA's client configures sshd with an AuthorizedKeysCommand that executes a program that queries sssd for the list of authorized keys for a given user. Sssd then uses a plugin to query the LDAP server @ FreeIPA to get the list of keys.
There's also SSHFP (I think) records in DNS if you're using FreeIPA's DNS servers. These provide the host keys for servers for your ssh client to check against. Not sure if that's integrated into ssh itself or something else -- I can't remember how it's implemented offhand -- but it's fairly nifty since you never see the TOFU prompt (or it would be if DNS was actually secure, anyway).
Re: SSH certificates: the better SSH experience
#107Earlier quoted context omitted.
A big problem I have with ssh carts is that they are not universally supported. For me, there is always some device or daemon (for example tinyssh in the initramfs of my gaming pc so that I can unlock it remotely) that only works with “plain old ssh keys”. And if I have to distribute and sync my keys onto a few hosts anyway, it takes away the benefits.
Adding to this: while certs are indeed well-supported by OpenSSH, it's not always the SSH daemon used on alternate or embedded platforms. For example, OpenWRT used Dropbear [1] instead, which does not support certs. Also, Java programs that implement SSH stuff, like Jenkins, may be doing so using Apache Mina [2] which, though the underlying library supports certs, it is buggy [3] and requires the application to add t…
You can just replace dropbear with openssh on OpenWRT. That was one of the first things I did, since DropBear also doesn't support hardware backed (sk) keys. Just move it to 2222 and disable the service.
I reenabled DB on that alt port when I did the recent major update, just in case, but it wasn't necessary. After the upgrade, OpenSSH was alive and ready.
Re: SSH certificates: the better SSH experience
#108One constant source of amazement for me is people not using ssh keys / using passwords with ssh. Especially at a BigCo, where there are different environments, with different passwords, and password expiry/rotation/complexity rules. Like, when asking for help, or working together... you say to them "ok, lets ssh to devfoo1234", and they do it, and then type in their password, and maybe get it wrong, then need to rese…
Since a few years now I only ever use SSH private keys safely hidden behind a HSM with a tinier than tiny attack surface: Yubikeys do it for me (but other vendors would work too). My SSH keys do not have a password but when I log in using SSH, it requires me to physically touch my Yubikey (well one of my Yubikeys).
Windows has great support, surprisingly, for TPM-backed sk keys using Windows Hello and OpenSSH. Protected with physical presence and anti-hammering at the hardware level, and easy to setup by just selecting a sk type key.
I only use password keys for things that need to be scripted.
Re: SSH certificates: the better SSH experience
#109shameless plug: I've been tinkering with a tool to make SSH certificate-based login a bit easier. it's called Sshifu.
basically, you set up a sshifu-server that acts as a certificate authority + SSO server. then on your SSH servers, you configure them to trust this CA (there are helper npx commands / bash scripts to make this easy).
after that, for each user who wants access, they just run:
npx sshifu
this starts the SSO login flow, sets up the CA public key if needed, and immediately opens an SSH session.
npx is just the easiest way to get started, there are other install options too.
I built this as a smaller alternative to Smallstep / Teleport. it's still very early and mostly vibe-coded, but it's already scratching my own itch.
would love to hear what you guys think
repo: github.com/azophy/sshifu
Re: SSH certificates: the better SSH experience
#110Earlier quoted context omitted.
I've known SSH certs for a while but never went through the effort of migrating away from keys. I'm very frustrated about manually managing my SSH keys across my different servers and devices though. I assume you gathered a lot of thoughts over these 15 years. Should I invest in making the switch?
You will have to manage your SSH CA certificates instead of your keys. The workflows SSH CA's are extremely janky and insecure. With some creative use of `AuthorizedKeysCommand` you can make SSH key rotation painless and secure. With SSH certificates you have to go back to the "keys to the kingdom" antipattern and just hope for the best.
[flagged]