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

A sane SSH(1) key management example

try.popho.be

Post reply on HN
Print view View original

61–69 of 69 posts

Re: A sane SSH(1) key management example

#61

Post by pxc »

tialaramex wrote: post #40
xaduha wrote: post #24

Earlier quoted context omitted.

Just tried this $ ssh whoami.filippo.io and it prints this You have SSH agent forwarding turned (universally?) on. That is a VERY BAD idea. For example, right now this server has access to your agent and can use your keys however it likes as long as you are connected. ANY SERVER YOU LOG IN TO AND ANYONE WITH ROOT ON THOSE SERVERS CAN LOGIN AS YOU ANYWHERE. but I very much doubt that, because I didn't authorize my sec…

Probably filippo should update this software to notice if the only identities presented were from FIDO authenticators and, if so, modify this message to explain the reduced risk Note that although it's likely yours always requires a presence check (e.g. touch sensor), OpenSSH does not by default tell FIDO authenticators that it insists on UP (User Present) and so they are entitled (but few do since WebAuthn always as…

> Probably filippo should update this software to notice if the only identities presented were from FIDO authenticators and, if so, modify this message to explain the reduced risk

The you can store non-FIDO keys on a hardware PGP device, use them for SSH authentication via GPG, and configure GPG to always require the same kind of UP checks for access to that subkey on the PGP smartcard. This gives you those same protections but doesn't show up to the server as any special key type.

As with the FIDO-based keytypes, you can (mis)configure this so it doesn't require UP checks at all.

Re: A sane SSH(1) key management example

#62

Post by rgoulter »

xaduha wrote: post #25
schaefer wrote: post #22

Earlier quoted context omitted.

Can you point to any existing write ups that are more in line with your methodology, for those of us that want to dig in and give it a try?

If you have Yubikey, then this is fine https://xeiaso.net/blog/yubikey-ssh-key-storage . I have Google Titan NFC which is basically Feitian K9 NFC, so it doesn't support -O resident. Back in 2016 I was using https://github.com/philipWendland/IsoApplet which uses https://en.wikipedia.org/wiki/PKCS_11 standard, but modern way is much smoother as long as your OpenSSH server is up to date.

FWIW, the method in that xeiaso link (using resident keys on a security key) can be done with the cheaper "Security Keys" from Yubico, and doesn't need the more expensive Yubikey. -- The cheaper security key can be used as a FIDO key as 2FA for many websites; or even for stuff like Linux login.

Re: A sane SSH(1) key management example

#63

Post by fmajid »

cassianoleal wrote: post #46

On Macs, Secretive [0] is great. It creates keys in the secret enclave, from where they can't be read, only used for signing requests. TouchID authorisation is optional but it's so quick and easy that I keep it on for all keys. It can also use Smart Cards (Yubikeys are called out by name in the readme). A forwarded agent will have the same level of security, meaning that if the forwarded agent needs to use a key in S…

OpenSSH since 8.2p1 supports FIDO2 U2F keys directly (via libfido) using no proprietary Yubikey functionality, as the new ed25519-sk key type (sk for security key). The server also needs to be 8.2+ but doesn’t need to be compiled with libfido.

Re: A sane SSH(1) key management example

#64

Post by cassianoleal »

fmajid wrote: post #63
cassianoleal wrote: post #46

On Macs, Secretive [0] is great. It creates keys in the secret enclave, from where they can't be read, only used for signing requests. TouchID authorisation is optional but it's so quick and easy that I keep it on for all keys. It can also use Smart Cards (Yubikeys are called out by name in the readme). A forwarded agent will have the same level of security, meaning that if the forwarded agent needs to use a key in S…

OpenSSH since 8.2p1 supports FIDO2 U2F keys directly (via libfido) using no proprietary Yubikey functionality, as the new ed25519-sk key type (sk for security key). The server also needs to be 8.2+ but doesn’t need to be compiled with libfido.

That's cool, but can it use the secret enclave and TouchID?

Re: A sane SSH(1) key management example

#65

Post by dinosaurdynasty »

Quekid5 wrote: post #59
dinosaurdynasty wrote: post #41

Earlier quoted context omitted.

If you distribute a key revocation list to your servers, it will override anything in anyone's authorized_keys file (on that server of course). Even with a CA approach (unless the expirations are sufficiently short) you will need to do something like this.

Yes, but if you're distributing revocation lists you might as well distribute new authorized_keys files? Or wait, maybe I'm misremembering... does sshd support querying remote revocation lists? If so, point conceded. You still have to have to worry about the scenario of DoS or similar preventing it from fetching new lists. (I don't trust revocation beyond as being a QoI thing.) I do favor the CA approach with e.g. 24…

> does sshd support querying remote revocation lists?

It doesn't AFAIK but it's not too hard to write a cronjob that `curl`s a secure endpoint occasionally (or `scp` or whatever).

Re: A sane SSH(1) key management example

#66

Post by fmajid »

cassianoleal wrote: post #64
fmajid wrote: post #63

Earlier quoted context omitted.

OpenSSH since 8.2p1 supports FIDO2 U2F keys directly (via libfido) using no proprietary Yubikey functionality, as the new ed25519-sk key type (sk for security key). The server also needs to be 8.2+ but doesn’t need to be compiled with libfido.

That's cool, but can it use the secret enclave and TouchID?

All but one of my Macs lack them. I also need a solution that works on Linux.

Re: A sane SSH(1) key management example

#67

Post by cassianoleal »

fmajid wrote: post #66
cassianoleal wrote: post #64

Earlier quoted context omitted.

That's cool, but can it use the secret enclave and TouchID?

All but one of my Macs lack them. I also need a solution that works on Linux.

I was asking about using the secure enclave and Touch ID via the direct support on OpenSSH.

As for cross-platform compat, I wonder if you can use the same keys on the Yubikey via both Secretive and the native OpenSSH support. If it does I might look again into getting a Yubikey.

Re: A sane SSH(1) key management example

#68

Post by Quekid5 »

dinosaurdynasty wrote: post #65
Quekid5 wrote: post #59

Earlier quoted context omitted.

Yes, but if you're distributing revocation lists you might as well distribute new authorized_keys files? Or wait, maybe I'm misremembering... does sshd support querying remote revocation lists? If so, point conceded. You still have to have to worry about the scenario of DoS or similar preventing it from fetching new lists. (I don't trust revocation beyond as being a QoI thing.) I do favor the CA approach with e.g. 24…

> does sshd support querying remote revocation lists? It doesn't AFAIK but it's not too hard to write a cronjob that `curl`s a secure endpoint occasionally (or `scp` or whatever).

That would be a Fail Open type solution which isn't exactly great where security is concerned.

Re: A sane SSH(1) key management example

#69

Post by EduardoRT »

jonnycomputer wrote: post #36
EduardoRT wrote: post #5

Earlier quoted context omitted.

Not a big deal at all considering that they're public keys, there's no security concern there. Feels weird, but it's like going into a building that requires a badge and showing proof that you actually own several keys, then the building guard telling you he needs X key to enter since that's the one they know, and it's authorized. All your public keys in your GitHub account are accessible through a link, just .keys>

There is a privacy concern. And that might end up being a security concern depending on the threat model (e.g. social engineering attacks).

So, you'd ask someone to SSH into a server, and you'll get some of his public keys (I think the default limit is 5 keys), what would you do with that? You can also just go to their GitHub profile and fetch the keys or ask them to send you their public keys, they're meant to be public after all.

Here's one of my public keys, for free: ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAICIc3nOnSnsiAdkjAdH5WR9enQiPYWq1zAVsTDt60e91

Post reply on HN