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

SSH certificates: the better SSH experience

jpmens.net

Post reply on HN
Print view View original

81–90 of 137 posts

Re: SSH certificates: the better SSH experience

#81

Post by pphysch »

blueflow wrote: post #52
TZubiri wrote: post #50

Earlier quoted context omitted.

The capacity to grant access as a specific remote user is present without certs as well right? The typical authorized_keys file lives under a user directory and grants access only to that user.

The main advantage of certificates is that you are able to do that from the CA without touching the target machine.

Certs may still be the right approach, but OpenSSH also supports an AuthorizedKeysCommand which could be a secure HTTPS request to a central server to pull down a dynamically generated authorized_keys file content for the particular user and host.

If your endpoints can securely and reliably reach a central server, this gives you maximum control (your authorized_keys HTTPS server can have any custom business logic you want) without having to deal with certs/CAs.

Re: SSH certificates: the better SSH experience

#82

Post by ngrilly »

jamiesonbecker wrote: post #80
ngrilly wrote: post #44

Earlier quoted context omitted.

How do you solve TOFU?

Well, TOFU is really just the model for how the chain of trust is established. In practice there isn’t really trust on first use : there’s verify the key matches what’s expected , or distribute keys out-of-band (including certs). If that verification step isn’t happening, then it’s not TOFU, it’s just blind trust. From an automation/autoscaling angle, the same thing shows up again: 1. either keys are pre-baked / dist…

I agree. I was just wondering if Userify had a solution for distribution the server signatures to the users.

Re: SSH certificates: the better SSH experience

#83

Post by pphysch »

tacostakohashi wrote: post #65

One 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…

Unregulated/decentralized SSH key usage (i.e. allowing ssh-copy-id) is a dream for hackers to move laterally through a network. That's why many orgs disable it, and otherwise haven't invested resources in getting a proper centralized CA/authz server set up.

Re: SSH certificates: the better SSH experience

#84

Post by bombcar »

tacostakohashi wrote: post #65

One 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…

Keys is great for individual use, or for company use if you have centralized key control (and issue one or more keys per user).

Often you either end up with one "dev ssh key" for all machines (which is bad) or you end up with people sharing around keys and unidentified keys on machines.

Passwords at least are "simple" for people to work with.

Re: SSH certificates: the better SSH experience

#85

Post by znpy »

It's very interesting that you can force the execution of a specific command.

I wonder if that can be somehow employed to somehow get kubectl to invoke ssh in order to get an authentication tokens.

I would be cool to authenticate to kubernetes via ssh.

Re: SSH certificates: the better SSH experience

#86

Post by AceJohnny2 »

anyfoo wrote: post #22
kaoD wrote: post #3

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

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 the UX to also support it.

[1] https://matt.ucc.asn.au/dropbear/dropbear.html

[2] https://mina.apache.org/sshd-project/

[3] I've been dealing for years with NullPointerExceptions causing the connection to crash when presented with certain ed25519 certificates.

Re: SSH certificates: the better SSH experience

#87

Post by znpy »

Tepix wrote: post #7

The author lists all the advantes of CA certificates, yet doesn't list the disadvantages. OTOH, all the many steps required to set it up make the disadvantages rather obvious. Also, I've never had a security issue due to TOFU, have you?

> Also, I've never had a security issue due to TOFU, have you?

You haven't yet had a security issue due to TOFU - FTFY.

Re: SSH certificates: the better SSH experience

#88

Post by TacticalCoder »

tacostakohashi wrote: post #65

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

Re: SSH certificates: the better SSH experience

#89

Post by TZubiri »

lokar wrote: post #75
blueflow wrote: post #52

Earlier quoted context omitted.

The main advantage of certificates is that you are able to do that from the CA without touching the target machine.

Exactly. This is really useful in larger organizations where you may want more complex rules on access. For example, you can easily build "break glass" or 2nd party approved access on demand. You can put whatever logic you need in a CA front-end. You can also make all the certs short-lived (and only store them in ram).

The way I've been doing that is with Shamir Secret Sharing and encrypting keys until glass-breaking is necessary.

Re: SSH certificates: the better SSH experience

#90

Post by icedchai »

yason wrote: post #60

Despite the drawbacks of its grassroot nature TOFU goes a looooong way. With my own machines I can just physically check that the server host key matches what the ssh client sees. Once TOFU looks good I'm all set with that host because I don't change any of the keys ever. In a no-frills corporate unix environment it's enough to have a list of the internal servers' public keys listed on an internal website, accessible…

I've been using SSH since 1996 and I've never once seen anyone actually verify a public key manually like that. If they can MITM your SSH server, why can't they MITM your internal web site? In common practice, TOFU is type "yes" and YOLO.
Post reply on HN