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

121–130 of 161 posts

Re: We need better support for SSH host certificates

#121

Post by mattpallissard »

, I really wish that the kerberos/gssapi folks had packaged everything up nicely for the web people to use. Between keytabs, derived credentials, and cross realm trust it really did solve nearly every authentication situation that people have.

I pine for a world in which we had made it more approachable for the people who just wanted to quickly build an application without learning about the underlying infrastructure.

I've been dealing with authn/authz for a long time and kerberos is still one of the best protocols in existence.

Re: We need better support for SSH host certificates

#122

Post by rakoo »

teddyh wrote: post #113
rakoo wrote: post #83

Earlier quoted context omitted.

The issue with DANE is that now the DNS becomes a new point of failure, which means higher attention to details, more scrutiny, heavier and more secure processes for the root signing ceremonies that require more activity. It recentralizes everything and makes "failing" easier.

The CA system is just multiple points of failure instead of one. One is better.

No, because if one CA is broken only the certificates it authored are vulnerable. It takes more to break the entire system.

Re: We need better support for SSH host certificates

#123

Post by xurukefi »

Avamander wrote: post #77
xurukefi wrote: post #20

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.

Don't we already implicitly have that sort of trust at the moment with TLS certs considering that proof of ownership via DNS is quite common? Actually, any domain-based validationi, i.e., also HTTP-01, is going to be flawed if you don't trust the registries.

Re: We need better support for SSH host certificates

#124

Post by VLM »

godelski wrote: post #27
purpleidea wrote: post #19

Since the blog author didn't mention it, or doesn't know about it, fun fact, you can store host keys in DNS (make sure to use DNSSEC too of course!) https://en.wikipedia.org/wiki/SSHFP_record Of course this has its own challenges, but if you automate your DNS, this can be neat! Cheers!

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...

Its the classic 'perfect is the enemy of good enough' derailer.

Re: We need better support for SSH host certificates

#125

Post by philo23 »

rhco wrote: post #8

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…

This is a bit off topic, but does anyone know how the mechanism that triggers the web page prompt from an ssh connection actually works? Is it some kind of alternate ssh authentication method (like password/publickey) or something entirely out-of-band coming directly from the VPN app intercepting the connection?

Ever since I saw it in action with Tailscale I've always wondered how it actually works, and I guess if anyone would know they'd be on HN

Re: We need better support for SSH host certificates

#126

Post by hamburglar »

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…

As pointed out, whether or not you go through a jump host isn’t relevant. We all go through jump hosts as well.

Besides, neither me nor GP is saying this needs to be a universal pattern. We are saying that it’s a viable pattern for a lot of orgs.

Re: We need better support for SSH host certificates

#127

Post by vdqtp3 »

throwaway892238 wrote: post #14

No, you need to abolish SSH. It's an incredibly limiting protocol that does not support modern computing needs. Hacks and add-ons solve some but never all of its many problems. Wire-level network protocols like Wireguard are somewhat useful, but largely a large step away from the modern best practices. We need more Zero Trust, Federated Identity, Fine-grained Access Control, and Least Privilege. Those solutions exist…

> worse than the alternatives

What alternative is there to SSH? You want to go back to telnet?

Re: We need better support for SSH host certificates

#128

Post by hamburglar »

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?

Never. I’ve been at this company for 8 years and owned literally thousands of hosts and we have a policy of no agent forwarding. I’ve always wondered when I would be limited by it but it simply hasn’t come up. It’s a huge security problem, so I’m quite happy with this.

Re: We need better support for SSH host certificates

#129

Post by michaelt »

gpderetta wrote: post #98
michaelt wrote: post #65

Earlier quoted context omitted.

In general for systems like this, you can open the browser link from a different host. For example, if I've SSHed from my laptop to Host A to Host B to Host C then need to authenticate a CLI program I'm running on Host C, the program can show a link in the terminal which I can open on my laptop.

Having to interact with the browser every time I need to ssh to a machine would be extremely painful. If key forwarding works, that might be workable. I'm extremely wary of non-standard ssh login processes as they tend to break basic scripting and tooling.

These tools usually cache your identity, so you might only need to go through a browser once a day.

Re: We need better support for SSH host certificates

#130

Post by mbreese »

j16sdiz wrote: post #49
9dev wrote: post #34

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

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.

> You don't want to save the fingerprint in a stale, insecure database like that.

I'm trying to figure out how having a stale fingerprint would be an automatic bad thing.

Let's assume you have a server with a fingerprint stored in DNS. Something happens and the server's certificate/key needs to change. So now you push out a new key fingerprint to DNS.

The failure mode for an out-of-date fingerprint would be to not trust the new server's key. In this case, the default failure mode is to fail safely. The client could then have a few new options, like querying the authoritative DNS server or prompt the user.

You can argue that you wouldn't want to have stale DNS caching in an automated system, but in a user-interactive mode, it's not the worst thing.

And for an automated system, the system should be robust enough to manage a bad fingerprint (fail safely again), or be in control of the entire infrastructure, including you DNS cache.

Or am I missing something?

Post reply on HN