Another problem with SSH is that people remove the key check completly in automations since some services just rotates the keys without telling. Or for being lazy.
We need better support for SSH host certificates
41–50 of 161 posts
Re: We need better support for SSH host certificates
#42Earlier quoted context omitted.
As far as I can tell, DNS-based authentication puts all the trust eggs in the DNS root basket, and then again, in the TLD basket. This seems incredibly brittle and fraught with peril. Am I missing something?
The usual counter-argument for https, is that the eggs are already in that basket since anyone with control of dns can just get a new certificate. For ssh that doesn't really apply as clearly though.
Getting a cert requires someone to either compromise the primary DNS server for the domain, or to compromise DNS in multiple independent locations to serve consistent false answers to the probes. It's true that much of the TLS ecosystem is somewhat bound to DNS being trustworthy, but not to the same extent that SSHFP is.
Re: We need better support for SSH host certificates
#43Yes! SSH certificates are awesome, both for host- and client-verification. Avoiding Trust on First Use is potentially a big benefit, but the workflow improvements for developers, and especially non-technical people, is a huge win too. At work, we switched to Step CA [1] about 2 years ago. The workflow for our developers looks like: 1. `ssh client-hosts-01` 2. Browser window opens prompting for AzureAD login 3. SSH co…
Now try to automate that.
Re: We need better support for SSH host certificates
#44Earlier quoted context omitted.
> Seems like a pretty way to solve this by having ssh clients check the TLS of the host If you're doing TLS then you might as well do HTTPS. GitHub already supports HTTPS and way more features for it than SSH, and HTTPS works over more networks than SSH does. Continuing to use SSH is literally just being obsessed with a backwards old protocol for nostalgia reasons.
> Continuing to use SSH is literally just being obsessed with a backwards old protocol for nostalgia reasons. Honest question: Client authorization (for private repos) is an important feature of SSH. How does this work with HTTPS? EDIT: I just remembered the existence of TLS client certificate authentication. I wonder if it's possible to use an SSH client key for this (making the server accept a self-signed client ce…
The usual way HTTPS client auth works is to issue some sort of persistent access token that then ends up sitting on the filesystem without any sort of additional protection, or alternatively to just fall back to username and password without any kind of MFA. It's somehow even worse than the SSH situation. The use of x509 client certs would be a huge improvement here, but I don't know of any git hosting services that support that.
Re: We need better support for SSH host certificates
#45Earlier quoted context omitted.
I don’t believe in the forbidden fruit ideology. If it’s stupid and works well, it isn’t stupid. People have been using DNS for all kinds of configuration for decades now, with great success. So what, other than a pedantic and grumpy programmer’s perspective, should keep us from using DNS for configuration records?
i'm reminded of theo deraadt's answer when asked in a /. ama about firewall on a floppy. > I must say that I am not a fan of these floppy-based routers. Essentially, you are taking one of the most unreliable pieces of storage known to man, and trying to build security infrastructure on it. That's madness. dns is not the foundation upon which you want to build your secure infrastructure.
I don’t know anything about the work you do, but of all distributed databases I wrangled with over the years, DNS wasn’t among them :-)
Besides, we’re not talking about secure infrastructure per se, but distributing public metadata for IP addresses. That sounds like the prime thing DNS has been invented for to me.
Re: We need better support for SSH host certificates
#46Earlier quoted context omitted.
If you are in the terminal and don't have access to a browser?
Not the OP but if anyone doesn’t have access to a browser in my org then I can safely say they’re not accessing from a company laptop and thus should be denied access.
You really never ssh from one remote server to another?
Re: We need better support for SSH host certificates
#47Yes! SSH certificates are awesome, both for host- and client-verification. Avoiding Trust on First Use is potentially a big benefit, but the workflow improvements for developers, and especially non-technical people, is a huge win too. At work, we switched to Step CA [1] about 2 years ago. The workflow for our developers looks like: 1. `ssh client-hosts-01` 2. Browser window opens prompting for AzureAD login 3. SSH co…
If you are in the terminal and don't have access to a browser?
With e.g Azure's CLI az you can specify a flag something like "--use-device-code" which shows a copy-pastable URL that you then can just visit in the browser (on a different device even).
Re: We need better support for SSH host certificates
#48Earlier quoted context omitted.
Not the OP but if anyone doesn’t have access to a browser in my org then I can safely say they’re not accessing from a company laptop and thus should be denied access.
You really never ssh from one remote server to another?
Not GP, but:
I do, however when I do this I make sure the certificate is signed with permit-agent-forwarding and demand people just forward their ssh agent on their laptops.
This also discourages people from leaving their SSH private key on a server just for ssh-ing into other servers in CRON instead of using a proper machine-key.
Re: We need better support for SSH host certificates
#49Earlier quoted context omitted.
A comment mentions it[0] (I'll repeat here for ease) > SSHFP: > https://www.rfc-editor.org/rfc/rfc4255 >> Re SSHFP: >> Regarding DNS as a database for keys... Please stop this madness. >> DNS isn't a database. >> It's not a configuration store. >> It was meant and should be used only for name resolution. [0] https://mjg59.dreamwidth.org/65874.html?thread=2106450#cmt21...
I don’t believe in the forbidden fruit ideology. If it’s stupid and works well, it isn’t stupid. People have been using DNS for all kinds of configuration for decades now, with great success. So what, other than a pedantic and grumpy programmer’s perspective, should keep us from using DNS for configuration records?
1. DNS is insecure.... DNSSEC, despite all the effort goes it, still does not work in most TLD and registers.
2. Cache. People are caching DNS aggressively. Often more aggressive than what the TTL allows.
You don't want to save the fingerprint in a stale, insecure database like that.
Re: We need better support for SSH host certificates
#50Earlier quoted context omitted.
Not the OP but if anyone doesn’t have access to a browser in my org then I can safely say they’re not accessing from a company laptop and thus should be denied access.
Not sure why you'd get downvoted for this comment. This is likely very applicable for many orgs that have operator workstation standards -- they're some kind of window/osx/linux box with a defined/enforced endpoint protection measures, and they all have a browser. Any device I can imagine ssh'ing from that doesn't have a browser is definitely out of policy.
because both of you narrow visioned the scenario to what you do daily. it is a common use case to ssh from a jump server, use ssh based CLI tools and debugging. the issue stems from windows users who are coupled to GUIs. the behavior pattern increases IT and DevOps costs unnecessarily.
an alternative example: our org solves the issue with TOTP, required every 8 hours for any operation; from ssh/git CLI based actions (prompted at the terminal) to SSO integrations. decoupling security from unrelated programs. simple and elegant.