81–90 of 161 posts
Yes! 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…
Yes! 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…
1. `ssh client-hosts-01`
2. Browser window opens prompting for AzureAD login
3. SSH connection is accepted
Earlier 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.
Earlier quoted context omitted.
I’d been wanting to use this for a while, but support is lacking for most DNS providers. Maybe it should go the way of SPF and reuse TXT instead. CloudFlare added support in 2018: https://blog.cloudflare.com/additional-record-types-availabl... AWS still doesn’t support it: http://web.archive.org/web/20210429183447/https://forums.aws... Namecheap doesn’t: https://www.namecheap.com/support/knowledgebase/article.aspx...…
It specifically needed to be its own record as the record requires DNSSEC to verify that the returned SSH key is trusted. Using TXT would be ridiculously insecure as it cannot force the DNSSEC verification step that SSHFP as a unique record gives. Definitely annoying, but does ensure that the returned SSH key is always correct and not from a forged record.
Yes! 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…
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 connection is accepted How is that simple, compared to `ssh -i .ssh/my-cert.rsa someone@destination --> connection is accepted, here's your prompt` ?
Earlier quoted context omitted.
This is such a nice and pragmatic solution. And yet for some reason people would rather prefer the CA madness we know in the HTTPS ecosystem to be established in the SSH world. I understand that DANE was ahead of its time which is why we settled with CAs for SSL certificates but can we please take a different route this time for SSH?
I'm going to skip the long part, but what you're basically requesting is that everyone must trust the countries operating their ccTLDs. Does that sound reasonable? I don't think so.
Yes! 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…
Which would mean you have one single point of attack/DOS/failure that needs to be kept utterly secure at all costs?
Yes! 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…
One thing I've never understood about SSH certificates for client identification - it looks like it causes the requirement that _at some point_ ssh private keys and the certificate private key need to both be in the same place? And if this is the case, then doesn't that imply that you need to have a service where users upload their private key? Which would mean you have one single point of attack/DOS/failure that nee…
Earlier quoted context omitted.
I’d been wanting to use this for a while, but support is lacking for most DNS providers. Maybe it should go the way of SPF and reuse TXT instead. CloudFlare added support in 2018: https://blog.cloudflare.com/additional-record-types-availabl... AWS still doesn’t support it: http://web.archive.org/web/20210429183447/https://forums.aws... Namecheap doesn’t: https://www.namecheap.com/support/knowledgebase/article.aspx...…
It specifically needed to be its own record as the record requires DNSSEC to verify that the returned SSH key is trusted. Using TXT would be ridiculously insecure as it cannot force the DNSSEC verification step that SSHFP as a unique record gives. Definitely annoying, but does ensure that the returned SSH key is always correct and not from a forged record.
I don't believe that that is true. DNSSEC RRSIG records are created over the entire result set. So even if there are numerous records returned, you should still be able to verify the signature. Also, there is nothing stopping you from also returning multiple SSHFP records in a single query.
However, SPF does have a design flaw (amongst many other) that the record is placed under the domain root, which is often already polluted with other records. This is why other standards that use TXT (DMARC, DKIM, BIMI, MTA-STS, TLSRPT, etc.) use a specific label prefix, or a selector. But this is not because of DNSSEC.
Earlier quoted context omitted.
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 connection is accepted How is that simple, compared to `ssh -i .ssh/my-cert.rsa someone@destination --> connection is accepted, here's your prompt` ?
The former is discoverable: it doesn't require developers having ANY knowledge of command switches (no matter how basic) nor following a set of out-of-band instructions; the "how to" is included within the workflow.