Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We need better support for SSH host certificates

mjg59.dreamwidth.org

Post reply on HN
Print view View original

151–160 of 161 posts

Re: We need better support for SSH host certificates

#151

Post by hnlmorg »

gpderetta wrote: post #46
hnlmorg wrote: post #32

Earlier 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?

I can count on 1 hand the number of reasons I might need to do that and on each occasion there’s usually a better approach.

To be clear, I’m not suggesting the GPs approach is “optimal”. But if you’ve gone to the trouble of setting that up then you should have already solved the problems of data sharing (mitigating the need for rsync), network segregation and secure access (negating the need for jump boxes), etc.

SSH is a fantastic tool but mature enterprise systems should have more robust solutions in place (and with more detailed audit logs than an rsync connection would produce) by the time you’re looking at using AD as your server auth.

Re: We need better support for SSH host certificates

#152

Post by hnlmorg »

0xedd wrote: post #50
hamburglar wrote: post #37

Earlier quoted context omitted.

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…

There are better ways to access remote servers than using a jump box. If you’ve gone to the lengths to tie SSH auth into a web based SSO then you should have at least set up you’re other infra to manage network access already (since that’s a far bigger security concern).

Plus, as others have said, you can jump through SSH sessions with on the client ssh command (ie without having to manually invoke ssh on the jump box).

Re: We need better support for SSH host certificates

#153

Post by teddyh »

rakoo wrote: post #148
teddyh wrote: post #145

Earlier quoted context omitted.

So? If an authoritative DNS server operator is broken, only the domains below that operator (in the DNS hierarchy) could be impacted.

DNSSEC relies on a hierarchy of trust, with a single root zone at the top. If the root zone has issues, the whole system breaks down. In contrast, there is no unique "root CA" that can fail.

If one CA fails, it can still issue certificates for all domains. You can’t avoid any bad CA by using a good CA; any other bad CA can still issue certs for your domains. The CA system as a whole can only ever be as good as its worst CA.

Re: We need better support for SSH host certificates

#154

Post by teddyh »

rakoo wrote: post #150
bawolff wrote: post #149

Earlier quoted context omitted.

A CA can sign for any site. I'd say a single CA compromise breaks the entire system until it is revoked. DNS root key compromise breaks the entire system until it is replaced. Not seeing a huge difference.

There are multiple "root" CAs. CA compromises happen all the time, and it has always been dealt with because the fact that multiple "roots" exists means each one has to be kept in check. It's also possible for you (or more realistically for a company) to have their own CA, with their own certificates for all the sites you need. Not being unique applies pressure on each member to behave correctly because it is possibl…

What could possibly happen to the root zone? What is the ”something wrong” which you say could happen? I want to see specifics. The CA system is frequently defended by describing its transparency, and how any bad CA will be discovered thereby. I want to know how a compromised root zone could be used in an actual attack, and how this specific attack is easier than attacking a CA quickly enough before discovery.

Re: We need better support for SSH host certificates

#155

Post by rfoo »

the8472 wrote: post #105
rfoo wrote: post #48

Earlier quoted context omitted.

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.

Agent forwarding has its own security issues, you're exposing all your credentials to the remote. It's better to configure jump hosts in your local ssh config.

There's SSH agent restriction now.

[1] https://www.openssh.com/agent-restrict.html

Re: We need better support for SSH host certificates

#156

Post by dane-pgp »

Avamander wrote: post #143
dane-pgp wrote: post #111

Earlier quoted context omitted.

Trusting the country that operates the ccTLD of your website is a much better situation than having to trust all the countries that have CAs operate in them. A malicious CA in one country can issue a fraudulent certificate for a site in another country, whereas the people operating .ru can't affect the records for example.us so the blast radius is limited by design. Moreover, no one is required to use a ccTLD, and th…

> A malicious CA in one country can issue a fraudulent certificate for a site in another country, whereas the people operating .ru can't affect the records for example.us so the blast radius is limited by design. Sure and they'll be quickly mistrusted. You can't really revoke DNNSEC trust of an ccTLD operator. > Moreover, no one is required to use a ccTLD, and there are hundreds of gTLDs to choose from, or you could…

> Sure and they'll be quickly mistrusted. You can't really revoke DNNSEC trust of an ccTLD operator.

But you don't have to, because the blast radius is so much smaller, and the incentives are aligned better. The reason why CAs require such extreme punishment for misbehaviour is that one bad CA can break the trust for every site on the web.

If a country decided to invalidate the security of (predominantly) its own citizens' websites then that wouldn't harm anyone who used any of the other ccTLDs in the world (not to mention the hundreds of gTLDs).

Also, I think you are over-estimating the ease with which a CA can be "quickly mistrusted". What is the record for how quickly a CA has been taken out of browsers' certificate stores, measured from the time of their first misissuance?

And I would argue that revoking CA trust to Let's Encrypt / IdenTrust would be much more disruptive than revoking a single ccTLD operator, since that would mean breaking most sites on the web. So DNSSEC is actually better in terms of the "too big to fail" problem.

> This is bypassing a dangerous design, at best.

But that's my point; DNSSEC lets you bypass the danger of a rogue issuer, by swapping to an alternate domain in the worst case, whereas with CAs you have to hope that the rogue issuer doesn't decide to target you, and wait for the bureaucratic and software update processes to remove that CA from all your users' browsers.

There are definitely limitations to the DNSSEC system as currently deployed, just as there were with the web PKI system before browsers started to patch all the holes in that, but I don't know why my position on this technical question is so controversial. Nevertheless, I really appreciate you taking the time to offer intelligent counter-arguments in your comment, thank you.

Re: We need better support for SSH host certificates

#157

Post by Avamander »

dane-pgp wrote: post #156
Avamander wrote: post #143

Earlier quoted context omitted.

> A malicious CA in one country can issue a fraudulent certificate for a site in another country, whereas the people operating .ru can't affect the records for example.us so the blast radius is limited by design. Sure and they'll be quickly mistrusted. You can't really revoke DNNSEC trust of an ccTLD operator. > Moreover, no one is required to use a ccTLD, and there are hundreds of gTLDs to choose from, or you could…

> Sure and they'll be quickly mistrusted. You can't really revoke DNNSEC trust of an ccTLD operator. But you don't have to, because the blast radius is so much smaller, and the incentives are aligned better. The reason why CAs require such extreme punishment for misbehaviour is that one bad CA can break the trust for every site on the web. If a country decided to invalidate the security of (predominantly) its own cit…

> But you don't have to, because the blast radius is so much smaller, and the incentives are aligned better.

Entire countries best case is a small blast radius? A small CA going rogue would have a much smaller one, when we're talking about best case. Worst case is massive either way (say LetsEncrypt and .com). People also buy a lot of domains ignoring the fact that they're ccTLDs. The mere implication that people should choose their domains considering this fact is terrible.

> The reason why CAs require such extreme punishment for misbehaviour is that one bad CA can break the trust for every site on the web.

They can, but it'll be discovered really quick, especially with CAA violations. This can't be said about DNSSEC, any key compromise and abuse is difficult if not impossible to detect. Imagine that but with DANE, indefinite MITM, scary.

> DNSSEC lets you bypass the danger of a rogue issuer, by swapping to an alternate domain in the worst case, whereas with CAs you have to hope that the rogue issuer doesn't decide to target you

That's an insane bypass though. "Just cut your arm off, then it won't hurt." Change your email, figure out how to patch millions of devices out in the wild, so many problems.

A rogue issuer is much less hassle short- and long-term to deal with. Most browsers ship CRLite or similar and can revoke the root quickly. You can resume operation with a new CA rather fast.

DNSSEC is a nice complement to WebPKI and vice versa, but for our all sake, it can't be the only source of trust.

Re: We need better support for SSH host certificates

#158

Post by tptacek »

dane-pgp wrote: post #156
Avamander wrote: post #143

Earlier quoted context omitted.

> A malicious CA in one country can issue a fraudulent certificate for a site in another country, whereas the people operating .ru can't affect the records for example.us so the blast radius is limited by design. Sure and they'll be quickly mistrusted. You can't really revoke DNNSEC trust of an ccTLD operator. > Moreover, no one is required to use a ccTLD, and there are hundreds of gTLDs to choose from, or you could…

> Sure and they'll be quickly mistrusted. You can't really revoke DNNSEC trust of an ccTLD operator. But you don't have to, because the blast radius is so much smaller, and the incentives are aligned better. The reason why CAs require such extreme punishment for misbehaviour is that one bad CA can break the trust for every site on the web. If a country decided to invalidate the security of (predominantly) its own cit…

The blast radius of .COM is ~most of the western Internet.

Re: We need better support for SSH host certificates

#159

Post by akerl_ »

dane-pgp wrote: post #156
Avamander wrote: post #143

Earlier quoted context omitted.

> A malicious CA in one country can issue a fraudulent certificate for a site in another country, whereas the people operating .ru can't affect the records for example.us so the blast radius is limited by design. Sure and they'll be quickly mistrusted. You can't really revoke DNNSEC trust of an ccTLD operator. > Moreover, no one is required to use a ccTLD, and there are hundreds of gTLDs to choose from, or you could…

> Sure and they'll be quickly mistrusted. You can't really revoke DNNSEC trust of an ccTLD operator. But you don't have to, because the blast radius is so much smaller, and the incentives are aligned better. The reason why CAs require such extreme punishment for misbehaviour is that one bad CA can break the trust for every site on the web. If a country decided to invalidate the security of (predominantly) its own cit…

It's interesting that all of your examples reference ccTLDs and gTLDs, and not like, ".com" and ".org".

Re: We need better support for SSH host certificates

#160

Post by dijit »

mynameisvlad wrote: post #118
simiones wrote: post #82

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` ?

It’s the exact same command as a regular SSH prompt and it generates and uses the cert. that seems very simple. Your command is disingenuous in that it only works if the certificate has already been issued to you. If you were to include issuance, your command would very much turn non-simple.

If I'm reading it right then there's a non-insignificant amount of setup necessary for the proposed approach anyway, generating and sharing a public key is much easier even for the customer/client.
Post reply on HN