15 ms·

Secretive: Store SSH Keys in the Secure Enclave

292 points by ValentineC 4y ago

throwawayacc5 4y ago
Practically an anti-pattern nowadays. Get a YubiKey and leverage SSH certificates.
- daave 4y ago
  This is a non-sequitur, even if you use SSH certificates you still need a public/private keypair, hosts just authorize the key by checking the signature from a trusted CA on the public half of the user key. The OP is about a way to store the private key part of the user key that can't be extracted even with physical access to the machine. So, this is an equivalent/alternative to using a YubiKey, that is conveniently built in to a popular piece of hardware; not something orthogonal to using SSH certificates.
  - tptacek 4y ago
    It's not really a non-sequitur. The idiom for SSH certificates is to be issued extremely short-term certificates in response to MFA authentication. You don't get long-term secrets in most SSH CA schemes.
    - daave 4y ago
      You're certainly more of an authority on it than I, so I trust when you say most schemes don't keep long-term keypairs around; but of the two companies I've worked at that use SSH CAs: one used Teleport, and the other had long-lived keypairs, but fairly-short-lived certificates -- you had to get your public key re-signed each day. They used Yubikeys to store (or maybe just unwrap?) the private key material during the SSH handshake; much as a TPM or the Secure Enclave could be used to do this.
      - camgas 4y ago
        My experience (over maybe 10 years of using SSH-CAs) was similar, I mean by using long-term key pairs (mostly for humans) and shorter certificates. I can imagine secretive to be a very useful tool for SSH-CAs and other uses. I also like the fact that you can't import a key, makes it pretty clear that A- it's a specific device, and B- there is a human adding their bio info to unlock it.
        tptacek 4y ago
        Your experience of SSH CAs is different from mine (that doesn't make it wrong). My experience is that the major motivation for SSH CAs is linking SSH authentication to MFA SSO. The long-lived secrets here are the MFA secrets.
        camgas 4y ago
        Very useful to know, thanks for explaining more. I am curious to know (if you happen to remember) if this was an off-the-shelf product, and if so which one? I assume the product was either an MFA device or an SSH/SSO solution or both.
        tptacek 4y ago
        I've worked with teams that did bespoke versions, but Teleport is the most popular implementation of the idea right now. The underlying idea is trivial, right? You have an SSO RP that is a CA, and issues short-lived certs based on SSO IdP logins; the simple SSH certificate machinery makes this work across your fleet.
      - deleted 4y ago
        [deleted]
    - blueflow 4y ago
      The certs are just an alternative to managing the authorized_keys server-side. That's it. What you said about MFA and not getting long-term secrets is some extra thing on top of it and not invalidating your parents point.
      - tptacek 4y ago
        No, that's not true. SSH keys are long-lived secrets, and certificates often deliberately aren't.
        blueflow 4y ago
        This is not what it is, this is how you specifically use them.
        tptacek 4y ago
        I understand what you're trying to say, but "The certs are just an alternative to managing the authorized_keys server-side" is just not correct. Certs can do things plain authorized_keys can't.
ahepp 4y ago
Wow, this is really exciting! I have wished something like this existed, I'll have to try it out. I would love to use touchID to protect my ssh keys instead of a password!
- dewey 4y ago
  If you are using 1Password it's also possible already: https://blog.1password.com/1password-ssh-agent/ https://blog.1password.com/1password-ssh-agent/
  - VoxPelli 4y ago
    I opted for this instead when I decided to look this up, works really great!
encryptluks2 4y ago
This is already possible and has been for some time on Linux using TPM. What is different about secure enclave, or is it just Apple lingo?
- tptacek 4y ago
  The Apple enclave is closer to a general-purpose computer (with a bunch of cryptographic infrastructure) than a TPM, but I think for this purpose the two concepts line up.
  - geocar 4y ago
    I think it's a critical difference that the Apple enclave has direct access to inputs (the touchid).
    - deleted 4y ago
      [deleted]
- mjg59 4y ago
  Using the Secure Enclave allows you to tie use of the key to biometric auth (which also serves as proof of physical presence). Even if someone compromises your system, they can't SSH as you without tricking you into mashing touchID.
- alwillis 4y ago
  The Secure Enclave is a dedicated secure subsystem integrated into Apple systems on chip (SoCs). The Secure Enclave is isolated from the main processor to provide an extra layer of security and is designed to keep sensitive user data secure even when the Application Processor kernel becomes compromised. It follows the same design principles as the SoC does—a boot ROM to establish a hardware root of trust, an AES engine for efficient and secure cryptographic operations, and protected memory. From "Apple Platform Security"—https://support.apple.com/guide/security/secure-enclave-sec59b0b31ff/web https://support.apple.com/guide/security/secure-enclave-sec5...
- geocar 4y ago
exabrial 4y ago
I’ll definitely give this a spin! My go to right now is using a gpg key with ssh subkey. The key is actually on YubiKey. Similar security properties but portable.
- computerfriend 4y ago
  If you're already using a Yubikey, you can use FIDO2-based SSH keys which work natively with ssh-agent.
  - meepmorp 4y ago
    Assuming both client and server are recent enough to recognize the resident key types and are configured to allow them. Source: I have to deal with some machines I can’t fix.
    - drdaeman 4y ago
      > I can't fix Do not be afraid! (I've messed with quite a few very ancient and messy systems, like Gentoos of a legal drinking age. Dissected their guts, extracted their hearts, made LD_PRELOAD crutches, containerized stuff to run on modern hardware - this kind of mix of software necromancery and archeology. It's not trivial, but quite doable.) Fortunately, SSH daemons are quite isolated components, so they can almost always be updated without affecting the system. It's possible to build a completely static OpenSSH daemon binary, and replace the ancient /usr/bin/sshd on the most ancient OS. And it will work. Of course, test ahead of time by running your `~/tmp/your-new-sshd -d -p 10022` and ensuring you still can log in. For cleanliness (not to screw the system even further), as long as that machine still has a functional packaging system - even if package repos are long gone, I would recommend wrapping this binary in a OS-native package format (.deb, .rpm or whatever it uses), making a quick-and-dirty backport (from a custom built static binary), and feeding it to the low-level package manager. Preferably, taking a backup of the original sshd package from the local package cache (or finding that exact same package in some online archive). I mean, I've put `sshd`s on all sort of embedded systems, Docker containers and whatnot. Even if you have some Gentoo or Slackware machine from early 2000s (or worse), I don't really see much problem in modernizing an SSH daemon there. The only exception I can imagine is if someone already runs a patched sshd and they can't (or won't risk) backport new stuff in there.
PointyFluff 4y ago
[dead]
LoganDark 4y ago
I've always been afraid to invest in something like a yubikey or even to use the TPM on any devices I own. I don't ever want to depend on "something I have" that can't be backed up or recovered in any way. As an example, when I started using a password manager last year, I also made sure to start hosting the (encrypted) passwords database publicly (on a web server) so that if I ever lose it for any reason (SSD fails, etc) I'll be able to download it back onto a computer and unlock it with my master password. If I ever lose my passwords database I'll also lose access to every internet account I've ever made. It would be far too risky to make it rely on any physical possession of mine. Some people (most people??) would feel safe knowing that it's impossible for anyone to get into their accounts without their yubikey, but I'd just always be afraid of losing the yubikey.
- aaomidi 4y ago
  Have more than one Yubikey, use paperbackup keys.
- user3939382 4y ago
  Best practice is to have multiple Yubikeys, at least 2-3. You could leave one with a trusted person or family member. The odds of losing all of them simultaneously are slim.
  - tjoff 4y ago
    Oh, I need a new account. Hang on, can we book a new meeting in two weeks? I have to gather all my security keys first.
  - NoZebra120vClip 4y ago
    This is great, if you rarely add/update secrets and you also have easy, quick access to that offsite storage. It's not so great if you're constantly tapping your friend because you need to swap Yubikeys again and you both just get sick of that rigmarole. When setting up Yubikey, I discovered a tool, I think it's called "paperkey" and it lets you print out a GPG key after minting it. Have fun typing that back in! OCR ahoy! It's lower-tech, but my solution is to always have a comprehensive catalog of plaintext backup secrets stored offsite. This won't rely on anything electronic and it's easy to use. You just have to make a good effort to guard it from prying eyes, at least any eyes that also know your username and password. And likewise to some of the GPs, I'm skeptical of anything based on possession of an electronic thing that functions properly. The Yubikey is the best yet, because it's simple, purpose-built, and "virtually indestructible" as the marketing copy says. I would even love one of those RSA gadgets with a built-in display for purpose-built TOTP functionality. But paper's the best backup yet. Don't discount paper!
dang 4y ago
Related: Secretive: An app for storing and managing SSH keys in the Secure Enclave - https://news.ycombinator.com/item?id=28853329 https://news.ycombinator.com/item?id=28853329 - Oct 2021 (11 comments) Secretive – macOS native app to store SSH keys in the Secure Enclave - https://news.ycombinator.com/item?id=23664129 https://news.ycombinator.com/item?id=23664129 - June 2020 (106 comments)
deleted 4y ago
[deleted]
buildbot 4y ago
NB: If you use this, make sure to backup the key somehow. About a year ago I tested this with a few servers and lost all of the keys when my Mac had a kernel panic that wiped the state of the Secure Enclave! Updates can do this too!
- riobard 4y ago
  Correct me if wrong, but I thought that you cannot extract the private key from the Secure Enclave at all?
  - pocketarc 4y ago
    Yes, you can’t extract it, the Secure Enclave can just create a key and has it to sign stuff. You can never actually grab it or access it for backing up, so it shouldn’t be your only way of accessing a server, there should be another authorised key that you do have access to.
  - friendzis 4y ago
    This is true for any [citation needed] hardware security module. The interface allows to store/generate secrets and request cryptographic operations (encryption, signing, etc). Aside from physically tampering with the chip to access bits in raw silicon there is no way for the secret itself to leave the chip. Software security modules behave the same way, with the exception that one does have software access to the backing encrypted storage.
    - Too 4y ago
      Yubikeys can be backed up, using what they call export under wrap. It requires you initially created the key with exportable flag. The idea is you do this on first use to create an encrypted backup and then instantly remove the exportable flag from the key you carry around day to day. As others already noted, having more than one key is a good idea anyway. If you are really serious, use ssh certificates so you don’t have to update every server with new keys. Just sign them with the root CA.
  - 4y ago
kylehotchkiss 4y ago
I wish Apple would add more native support for this somehow. Until then, I’ve enjoyed using 1Pass for SSH key which continently allows me to share keys across machines, work confidently knowing my key isn’t accessible if a machine is lost, and asks me for Touch ID permission
- mjg59 4y ago
  Apple actually made this much harder than it should be by special-casing P256 ECDSA in their build of libressl, which means trying to use it with PKCS#11 breaks: https://mjg59.dreamwidth.org/64968.html https://mjg59.dreamwidth.org/64968.html . The approach Secretive uses (which is what I ended up mimicking) is using the SSH agent protocol rather than PKCS#11, which lets you do the crypto in your own codebase instead.
mjg59 4y ago
Secretive has to function as both a key generation utility and an SSH agent because of a restriction in Apple's Secure Enclave functionality - only the app that generates a key is allowed to use it. There's actually a workaround for this, which is to use https://developer.apple.com/documentation/cryptotokenkit https://developer.apple.com/documentation/cryptotokenkit to expose keys to the user keychain, which then means the tool used for key generation doesn't have to be the same tool that allows applications to make use of that key. We're using this internally to generate keys that are then combined with user creds to receive x.509 and ssh certificates, and exposing the ssh certs to ssh using the SSH agent protocol. Our next step is to take that a step further and use https://developer.apple.com/documentation/devicecheck/accessing_and_modifying_per-device_data https://developer.apple.com/documentation/devicecheck/access... to verify that the device asking for a cert is a device that we own (IT will be able to set one of those bits during device provisioning, and then we query that data during certificate issuance to show that the request comes from something we provisioned)
- smoothgrammer 4y ago
  Make sure you sign the information that indicates the requestor.
nelox 4y ago
This is excellent. A different way of enhancing the security of a private key is to use a passphrase and store the passphrase in the macOS Keychain. Then, configure ssh-agent to always use the Keychain. When you login to your Mac user account, it will unlock it for use with ssh. The encryption key needed to decrypt the Keychain is stored inside the Secure Enclave. If someone manages obtain your private key, they would also need guess your passphrase or gain access to the Secure Enclave.
macrolime 4y ago
How I'm setting up SSH access currently is to use two factor authentication where one of the factors is a device identifier, i.e. SSH key stored in TPM or with this on the Secure Enclave on a Mac, allowing only access from trusted devices. The second is a user identifier, stored in a yubikey. In sshd_config, you can enable multifactor authentication with a comma separated list after AuthenticationMethods, for example publickey, publickey to require two keys. https://manpages.debian.org/bullseye/openssh-server/sshd_config.5.en.html#AuthenticationMethods https://manpages.debian.org/bullseye/openssh-server/sshd_con...
- MaxMatti 4y ago
  Wouldn't that mean that I can login with any two keys? So instead of laptop+yubikey I could login with the keys from two laptops? Or from two yubikeys?
- aprilnya 4y ago
  What if someone gets 2 of the yubikeys?
nixpulvis 4y ago
What I kinda want is a way to use a detachable hardware key like a Yubikey as a primary factor for SSH and login authentication. I have multiple computers and I provision new OSes frequently and I always find it irritating depending on either network or flash drive synchronization for secret material when I could just be plugging in a smartcard device. Anyone gone down this path?
- als0 4y ago
  YubiKey already supports those scenarios, I think.
- MadQ 4y ago
  This is possible with PGP Keys stored on the Yubikey and used as the SSH keys. Check the Repo of drduh as a starting point https://github.com/drduh/YubiKey-Guide#ssh https://github.com/drduh/YubiKey-Guide#ssh
  - nixpulvis 4y ago
    Correct me if I'm wrong or missing something, but doesn't the use of SSH resident keys still require a file to be present on the client before it can authenticate? I'm prompted to use the SK to prove my 'presence' after the standard identity secret keyfile is checked. To be clear, my goal is to simply plug in my SK to a fresh OS install and "magically" be able to SSH into my servers.
    - acdha 4y ago
      That’s how it works for me. I generated a new key on the device, installed the public key where appropriate, and tap to authenticate. https://support.apple.com/en-us/HT208372 https://support.apple.com/en-us/HT208372 https://playbooks.idmanagement.gov/piv/engineer/ssh/ https://playbooks.idmanagement.gov/piv/engineer/ssh/
    - trevorthejag 4y ago
      Maybe not “magic” but you can get very close to that with “Discoverable Credentials” on a FIDO2 key. The process for using a discoverable key on a new machine re-imports the relevant public key and private key handle to the new machine when you “ssh-keygen -K”. Its roughly equivalent to copying key material around with a flash drive, but without the need to remember two physical items.
obscurette 4y ago
Looked at it at some point with hope that it'd provide easier user experience to use SSH with Yubikey PIV functionality on Mac. Unfortunately it doesn't support RSA keys we have to use for various reasons. https://github.com/maxgoedjen/secretive/issues/10 https://github.com/maxgoedjen/secretive/issues/10
- mjg59 4y ago
  It's not really so much that Secretive doesn't support RSA keys, it's that the SE doesn't
wslh 4y ago
I don't think the secure enclave is the solution. Identities should be independent than general computation devices with many attack vectors.
- yunohn 4y ago
  Not sure what you mean? The point of storing SSH keys in the Secure Enclave is to prevent against the default of /literally any/ program from reading them in plain text off your file system.
  - wslh 4y ago
    I mean [1] and [2]. General computation devices have wide attack vectors than specific security devices. [1] An Overview of Vulnerabilities and Mitigations of Intel SGX Applications: https://cyber.ee/uploads/D_2_116_An_Overview_of_Vulnerabilities_and_Mitigations_of_Intel_SGX_Applications_c1282b1505.pdf https://cyber.ee/uploads/D_2_116_An_Overview_of_Vulnerabilit... [2] https://www.google.com/search?q=security+enclave+vulnerabilities+site%3Areddit.com&rlz=1C5CHFA_enAR1036AR1039&sxsrf=AJOqlzVm6qqJOKevyhM5xhpRE6quMWwI5A%3A1678445436228&ei=fAsLZIzQDZ7D5OUPsaS32Ac&ved=0ahUKEwiM_oDAmNH9AhWeIbkGHTHSDXsQ4dUDCA8&uact=5&oq=security+enclave+vulnerabilities+site%3Areddit.com&gs_lcp=Cgxnd3Mtd2l6LXNlcnAQA0oECEEYAVDiBFi4C2CwDWgBcAB4AIABV4gB9gGSAQE0mAEAoAEBwAEB&sclient=gws-wiz-serp https://www.google.com/search?q=security+enclave+vulnerabili...
    - yunohn 4y ago
      Sure, nobody said there can’t be vulnerabilities in the Secure Enclave or similar options. The default alternative is globally-readable plain text. Don’t let perfection be the enemy of good/better.
      - wslh 4y ago
        > Don’t let perfection be the enemy of good/better. I agree, it is just that we add a new element of security which has other security issues while we can move directly outside the computer. Apple move to U2F as a 2FA is a clear execution.
VoxPelli 4y ago
I was considering this but ultimately opted for 1Password’s SSH Agent instead and storing my SSH keys there and unlocking it with Touch ID: https://developer.1password.com/docs/ssh/agent/ https://developer.1password.com/docs/ssh/agent/ Also use it to sign my git commits: https://developer.1password.com/docs/ssh/git-commit-signing https://developer.1password.com/docs/ssh/git-commit-signing
- e1g 4y ago
  I have the same setup and can vouch that it works very well. My primary threat vector is data exfiltration by a compromised binary/node_module. A script reads everything in $HOME and sends it offsite. This is challenging to defend against, considering how many secrets want to live in plain text files (dot files, DB, AWS configs, backups, ssh keys, etc.), and file permissions do not help when the script runs with my user privileges.
rollcat 4y ago
Unfortunately the SEP only supports ECDSA keys. https://blog.cr.yp.to/20140323-ecdsa.html https://blog.cr.yp.to/20140323-ecdsa.html
deleted 4y ago
[deleted]
nyolfen 4y ago
there was a cool app called krypt that did this for ios, with push notifications to your phone when you ssh'd, where requests were authenticated against your secure enclave. then it got bought by akamai and turned into some b2b saas crap.
WhyNotHugo 4y ago
Doesn't Secure Enclave offer a smartcard-like interface on macOS? SSH already supports using hardware-backed keys via smartcard interfaces, so such an interface would allow it to work without any extra moving parts. I keep seeing lots of new programs that are basically "Secure Enclave for X", where X already supports hardware-based keys via existing interfaces.
- mjg59 4y ago
  Not directly - you can use CryptoTokenKit to bind SE keys into the keychain as if they were a smartcard, but there's no shipped tooling for that.
rgreen 4y ago
Secretive is one of my favorite tools on mac os. it's the best ssh workflow i've used: key material never leaves the device, can auth with touch id, and forward the agent as necessary. i've also sent him $ on github as a small thank you for a tool i use daily (and i'd encourage you to, too!)

292 points by ValentineC 4y ago

throwawayacc5 4y ago

Practically an anti-pattern nowadays. Get a YubiKey and leverage SSH certificates.

daave 4y ago
This is a non-sequitur, even if you use SSH certificates you still need a public/private keypair, hosts just authorize the key by checking the signature from a trusted CA on the public half of the user key. The OP is about a way to store the private key part of the user key that can't be extracted even with physical access to the machine. So, this is an equivalent/alternative to using a YubiKey, that is conveniently built in to a popular piece of hardware; not something orthogonal to using SSH certificates.
- tptacek 4y ago
  It's not really a non-sequitur. The idiom for SSH certificates is to be issued extremely short-term certificates in response to MFA authentication. You don't get long-term secrets in most SSH CA schemes.
  - daave 4y ago
    You're certainly more of an authority on it than I, so I trust when you say most schemes don't keep long-term keypairs around; but of the two companies I've worked at that use SSH CAs: one used Teleport, and the other had long-lived keypairs, but fairly-short-lived certificates -- you had to get your public key re-signed each day. They used Yubikeys to store (or maybe just unwrap?) the private key material during the SSH handshake; much as a TPM or the Secure Enclave could be used to do this.
    - camgas 4y ago
      My experience (over maybe 10 years of using SSH-CAs) was similar, I mean by using long-term key pairs (mostly for humans) and shorter certificates. I can imagine secretive to be a very useful tool for SSH-CAs and other uses. I also like the fact that you can't import a key, makes it pretty clear that A- it's a specific device, and B- there is a human adding their bio info to unlock it.
      - tptacek 4y ago
        Your experience of SSH CAs is different from mine (that doesn't make it wrong). My experience is that the major motivation for SSH CAs is linking SSH authentication to MFA SSO. The long-lived secrets here are the MFA secrets.
        camgas 4y ago
        Very useful to know, thanks for explaining more. I am curious to know (if you happen to remember) if this was an off-the-shelf product, and if so which one? I assume the product was either an MFA device or an SSH/SSO solution or both.
        tptacek 4y ago
        I've worked with teams that did bespoke versions, but Teleport is the most popular implementation of the idea right now. The underlying idea is trivial, right? You have an SSO RP that is a CA, and issues short-lived certs based on SSO IdP logins; the simple SSH certificate machinery makes this work across your fleet.
    - deleted 4y ago
      [deleted]
  - blueflow 4y ago
    The certs are just an alternative to managing the authorized_keys server-side. That's it. What you said about MFA and not getting long-term secrets is some extra thing on top of it and not invalidating your parents point.
    - tptacek 4y ago
      No, that's not true. SSH keys are long-lived secrets, and certificates often deliberately aren't.
      - blueflow 4y ago
        This is not what it is, this is how you specifically use them.
        tptacek 4y ago
        I understand what you're trying to say, but "The certs are just an alternative to managing the authorized_keys server-side" is just not correct. Certs can do things plain authorized_keys can't.

ahepp 4y ago

Wow, this is really exciting! I have wished something like this existed, I'll have to try it out. I would love to use touchID to protect my ssh keys instead of a password!

dewey 4y ago
If you are using 1Password it's also possible already: https://blog.1password.com/1password-ssh-agent/ https://blog.1password.com/1password-ssh-agent/
- VoxPelli 4y ago
  I opted for this instead when I decided to look this up, works really great!

encryptluks2 4y ago

This is already possible and has been for some time on Linux using TPM. What is different about secure enclave, or is it just Apple lingo?

tptacek 4y ago
The Apple enclave is closer to a general-purpose computer (with a bunch of cryptographic infrastructure) than a TPM, but I think for this purpose the two concepts line up.
- geocar 4y ago
  I think it's a critical difference that the Apple enclave has direct access to inputs (the touchid).
  - deleted 4y ago
    [deleted]
mjg59 4y ago
Using the Secure Enclave allows you to tie use of the key to biometric auth (which also serves as proof of physical presence). Even if someone compromises your system, they can't SSH as you without tricking you into mashing touchID.
alwillis 4y ago
The Secure Enclave is a dedicated secure subsystem integrated into Apple systems on chip (SoCs). The Secure Enclave is isolated from the main processor to provide an extra layer of security and is designed to keep sensitive user data secure even when the Application Processor kernel becomes compromised. It follows the same design principles as the SoC does—a boot ROM to establish a hardware root of trust, an AES engine for efficient and secure cryptographic operations, and protected memory. From "Apple Platform Security"—https://support.apple.com/guide/security/secure-enclave-sec59b0b31ff/web https://support.apple.com/guide/security/secure-enclave-sec5...
geocar 4y ago

exabrial 4y ago

I’ll definitely give this a spin! My go to right now is using a gpg key with ssh subkey. The key is actually on YubiKey. Similar security properties but portable.

computerfriend 4y ago
If you're already using a Yubikey, you can use FIDO2-based SSH keys which work natively with ssh-agent.
- meepmorp 4y ago
  Assuming both client and server are recent enough to recognize the resident key types and are configured to allow them. Source: I have to deal with some machines I can’t fix.
  - drdaeman 4y ago
    > I can't fix Do not be afraid! (I've messed with quite a few very ancient and messy systems, like Gentoos of a legal drinking age. Dissected their guts, extracted their hearts, made LD_PRELOAD crutches, containerized stuff to run on modern hardware - this kind of mix of software necromancery and archeology. It's not trivial, but quite doable.) Fortunately, SSH daemons are quite isolated components, so they can almost always be updated without affecting the system. It's possible to build a completely static OpenSSH daemon binary, and replace the ancient /usr/bin/sshd on the most ancient OS. And it will work. Of course, test ahead of time by running your `~/tmp/your-new-sshd -d -p 10022` and ensuring you still can log in. For cleanliness (not to screw the system even further), as long as that machine still has a functional packaging system - even if package repos are long gone, I would recommend wrapping this binary in a OS-native package format (.deb, .rpm or whatever it uses), making a quick-and-dirty backport (from a custom built static binary), and feeding it to the low-level package manager. Preferably, taking a backup of the original sshd package from the local package cache (or finding that exact same package in some online archive). I mean, I've put `sshd`s on all sort of embedded systems, Docker containers and whatnot. Even if you have some Gentoo or Slackware machine from early 2000s (or worse), I don't really see much problem in modernizing an SSH daemon there. The only exception I can imagine is if someone already runs a patched sshd and they can't (or won't risk) backport new stuff in there.

PointyFluff 4y ago

[dead]

LoganDark 4y ago

I've always been afraid to invest in something like a yubikey or even to use the TPM on any devices I own. I don't ever want to depend on "something I have" that can't be backed up or recovered in any way. As an example, when I started using a password manager last year, I also made sure to start hosting the (encrypted) passwords database publicly (on a web server) so that if I ever lose it for any reason (SSD fails, etc) I'll be able to download it back onto a computer and unlock it with my master password. If I ever lose my passwords database I'll also lose access to every internet account I've ever made. It would be far too risky to make it rely on any physical possession of mine. Some people (most people??) would feel safe knowing that it's impossible for anyone to get into their accounts without their yubikey, but I'd just always be afraid of losing the yubikey.

aaomidi 4y ago
Have more than one Yubikey, use paperbackup keys.
user3939382 4y ago
Best practice is to have multiple Yubikeys, at least 2-3. You could leave one with a trusted person or family member. The odds of losing all of them simultaneously are slim.
- tjoff 4y ago
  Oh, I need a new account. Hang on, can we book a new meeting in two weeks? I have to gather all my security keys first.
- NoZebra120vClip 4y ago
  This is great, if you rarely add/update secrets and you also have easy, quick access to that offsite storage. It's not so great if you're constantly tapping your friend because you need to swap Yubikeys again and you both just get sick of that rigmarole. When setting up Yubikey, I discovered a tool, I think it's called "paperkey" and it lets you print out a GPG key after minting it. Have fun typing that back in! OCR ahoy! It's lower-tech, but my solution is to always have a comprehensive catalog of plaintext backup secrets stored offsite. This won't rely on anything electronic and it's easy to use. You just have to make a good effort to guard it from prying eyes, at least any eyes that also know your username and password. And likewise to some of the GPs, I'm skeptical of anything based on possession of an electronic thing that functions properly. The Yubikey is the best yet, because it's simple, purpose-built, and "virtually indestructible" as the marketing copy says. I would even love one of those RSA gadgets with a built-in display for purpose-built TOTP functionality. But paper's the best backup yet. Don't discount paper!

dang 4y ago

Related: Secretive: An app for storing and managing SSH keys in the Secure Enclave - https://news.ycombinator.com/item?id=28853329 https://news.ycombinator.com/item?id=28853329 - Oct 2021 (11 comments) Secretive – macOS native app to store SSH keys in the Secure Enclave - https://news.ycombinator.com/item?id=23664129 https://news.ycombinator.com/item?id=23664129 - June 2020 (106 comments)

deleted 4y ago

[deleted]

buildbot 4y ago

NB: If you use this, make sure to backup the key somehow. About a year ago I tested this with a few servers and lost all of the keys when my Mac had a kernel panic that wiped the state of the Secure Enclave! Updates can do this too!

riobard 4y ago
Correct me if wrong, but I thought that you cannot extract the private key from the Secure Enclave at all?
- pocketarc 4y ago
  Yes, you can’t extract it, the Secure Enclave can just create a key and has it to sign stuff. You can never actually grab it or access it for backing up, so it shouldn’t be your only way of accessing a server, there should be another authorised key that you do have access to.
- friendzis 4y ago
  This is true for any [citation needed] hardware security module. The interface allows to store/generate secrets and request cryptographic operations (encryption, signing, etc). Aside from physically tampering with the chip to access bits in raw silicon there is no way for the secret itself to leave the chip. Software security modules behave the same way, with the exception that one does have software access to the backing encrypted storage.
  - Too 4y ago
    Yubikeys can be backed up, using what they call export under wrap. It requires you initially created the key with exportable flag. The idea is you do this on first use to create an encrypted backup and then instantly remove the exportable flag from the key you carry around day to day. As others already noted, having more than one key is a good idea anyway. If you are really serious, use ssh certificates so you don’t have to update every server with new keys. Just sign them with the root CA.
- 4y ago

kylehotchkiss 4y ago

I wish Apple would add more native support for this somehow. Until then, I’ve enjoyed using 1Pass for SSH key which continently allows me to share keys across machines, work confidently knowing my key isn’t accessible if a machine is lost, and asks me for Touch ID permission

mjg59 4y ago
Apple actually made this much harder than it should be by special-casing P256 ECDSA in their build of libressl, which means trying to use it with PKCS#11 breaks: https://mjg59.dreamwidth.org/64968.html https://mjg59.dreamwidth.org/64968.html . The approach Secretive uses (which is what I ended up mimicking) is using the SSH agent protocol rather than PKCS#11, which lets you do the crypto in your own codebase instead.

mjg59 4y ago

Secretive has to function as both a key generation utility and an SSH agent because of a restriction in Apple's Secure Enclave functionality - only the app that generates a key is allowed to use it. There's actually a workaround for this, which is to use https://developer.apple.com/documentation/cryptotokenkit https://developer.apple.com/documentation/cryptotokenkit to expose keys to the user keychain, which then means the tool used for key generation doesn't have to be the same tool that allows applications to make use of that key. We're using this internally to generate keys that are then combined with user creds to receive x.509 and ssh certificates, and exposing the ssh certs to ssh using the SSH agent protocol. Our next step is to take that a step further and use https://developer.apple.com/documentation/devicecheck/accessing_and_modifying_per-device_data https://developer.apple.com/documentation/devicecheck/access... to verify that the device asking for a cert is a device that we own (IT will be able to set one of those bits during device provisioning, and then we query that data during certificate issuance to show that the request comes from something we provisioned)

smoothgrammer 4y ago
Make sure you sign the information that indicates the requestor.

nelox 4y ago

This is excellent. A different way of enhancing the security of a private key is to use a passphrase and store the passphrase in the macOS Keychain. Then, configure ssh-agent to always use the Keychain. When you login to your Mac user account, it will unlock it for use with ssh. The encryption key needed to decrypt the Keychain is stored inside the Secure Enclave. If someone manages obtain your private key, they would also need guess your passphrase or gain access to the Secure Enclave.

macrolime 4y ago

How I'm setting up SSH access currently is to use two factor authentication where one of the factors is a device identifier, i.e. SSH key stored in TPM or with this on the Secure Enclave on a Mac, allowing only access from trusted devices. The second is a user identifier, stored in a yubikey. In sshd_config, you can enable multifactor authentication with a comma separated list after AuthenticationMethods, for example publickey, publickey to require two keys. https://manpages.debian.org/bullseye/openssh-server/sshd_config.5.en.html#AuthenticationMethods https://manpages.debian.org/bullseye/openssh-server/sshd_con...

MaxMatti 4y ago
Wouldn't that mean that I can login with any two keys? So instead of laptop+yubikey I could login with the keys from two laptops? Or from two yubikeys?
aprilnya 4y ago
What if someone gets 2 of the yubikeys?

nixpulvis 4y ago

What I kinda want is a way to use a detachable hardware key like a Yubikey as a primary factor for SSH and login authentication. I have multiple computers and I provision new OSes frequently and I always find it irritating depending on either network or flash drive synchronization for secret material when I could just be plugging in a smartcard device. Anyone gone down this path?

als0 4y ago
YubiKey already supports those scenarios, I think.
MadQ 4y ago
This is possible with PGP Keys stored on the Yubikey and used as the SSH keys. Check the Repo of drduh as a starting point https://github.com/drduh/YubiKey-Guide#ssh https://github.com/drduh/YubiKey-Guide#ssh
- nixpulvis 4y ago
  Correct me if I'm wrong or missing something, but doesn't the use of SSH resident keys still require a file to be present on the client before it can authenticate? I'm prompted to use the SK to prove my 'presence' after the standard identity secret keyfile is checked. To be clear, my goal is to simply plug in my SK to a fresh OS install and "magically" be able to SSH into my servers.
  - acdha 4y ago
    That’s how it works for me. I generated a new key on the device, installed the public key where appropriate, and tap to authenticate. https://support.apple.com/en-us/HT208372 https://support.apple.com/en-us/HT208372 https://playbooks.idmanagement.gov/piv/engineer/ssh/ https://playbooks.idmanagement.gov/piv/engineer/ssh/
  - trevorthejag 4y ago
    Maybe not “magic” but you can get very close to that with “Discoverable Credentials” on a FIDO2 key. The process for using a discoverable key on a new machine re-imports the relevant public key and private key handle to the new machine when you “ssh-keygen -K”. Its roughly equivalent to copying key material around with a flash drive, but without the need to remember two physical items.

obscurette 4y ago

Looked at it at some point with hope that it'd provide easier user experience to use SSH with Yubikey PIV functionality on Mac. Unfortunately it doesn't support RSA keys we have to use for various reasons. https://github.com/maxgoedjen/secretive/issues/10 https://github.com/maxgoedjen/secretive/issues/10

mjg59 4y ago
It's not really so much that Secretive doesn't support RSA keys, it's that the SE doesn't

wslh 4y ago

I don't think the secure enclave is the solution. Identities should be independent than general computation devices with many attack vectors.

yunohn 4y ago
Not sure what you mean? The point of storing SSH keys in the Secure Enclave is to prevent against the default of /literally any/ program from reading them in plain text off your file system.
- wslh 4y ago
  I mean [1] and [2]. General computation devices have wide attack vectors than specific security devices. [1] An Overview of Vulnerabilities and Mitigations of Intel SGX Applications: https://cyber.ee/uploads/D_2_116_An_Overview_of_Vulnerabilities_and_Mitigations_of_Intel_SGX_Applications_c1282b1505.pdf https://cyber.ee/uploads/D_2_116_An_Overview_of_Vulnerabilit... [2] https://www.google.com/search?q=security+enclave+vulnerabilities+site%3Areddit.com&rlz=1C5CHFA_enAR1036AR1039&sxsrf=AJOqlzVm6qqJOKevyhM5xhpRE6quMWwI5A%3A1678445436228&ei=fAsLZIzQDZ7D5OUPsaS32Ac&ved=0ahUKEwiM_oDAmNH9AhWeIbkGHTHSDXsQ4dUDCA8&uact=5&oq=security+enclave+vulnerabilities+site%3Areddit.com&gs_lcp=Cgxnd3Mtd2l6LXNlcnAQA0oECEEYAVDiBFi4C2CwDWgBcAB4AIABV4gB9gGSAQE0mAEAoAEBwAEB&sclient=gws-wiz-serp https://www.google.com/search?q=security+enclave+vulnerabili...
  - yunohn 4y ago
    Sure, nobody said there can’t be vulnerabilities in the Secure Enclave or similar options. The default alternative is globally-readable plain text. Don’t let perfection be the enemy of good/better.
    - wslh 4y ago
      > Don’t let perfection be the enemy of good/better. I agree, it is just that we add a new element of security which has other security issues while we can move directly outside the computer. Apple move to U2F as a 2FA is a clear execution.

VoxPelli 4y ago

I was considering this but ultimately opted for 1Password’s SSH Agent instead and storing my SSH keys there and unlocking it with Touch ID: https://developer.1password.com/docs/ssh/agent/ https://developer.1password.com/docs/ssh/agent/ Also use it to sign my git commits: https://developer.1password.com/docs/ssh/git-commit-signing https://developer.1password.com/docs/ssh/git-commit-signing

e1g 4y ago
I have the same setup and can vouch that it works very well. My primary threat vector is data exfiltration by a compromised binary/node_module. A script reads everything in $HOME and sends it offsite. This is challenging to defend against, considering how many secrets want to live in plain text files (dot files, DB, AWS configs, backups, ssh keys, etc.), and file permissions do not help when the script runs with my user privileges.

rollcat 4y ago

Unfortunately the SEP only supports ECDSA keys. https://blog.cr.yp.to/20140323-ecdsa.html https://blog.cr.yp.to/20140323-ecdsa.html

deleted 4y ago

[deleted]

nyolfen 4y ago

there was a cool app called krypt that did this for ios, with push notifications to your phone when you ssh'd, where requests were authenticated against your secure enclave. then it got bought by akamai and turned into some b2b saas crap.

WhyNotHugo 4y ago

Doesn't Secure Enclave offer a smartcard-like interface on macOS? SSH already supports using hardware-backed keys via smartcard interfaces, so such an interface would allow it to work without any extra moving parts. I keep seeing lots of new programs that are basically "Secure Enclave for X", where X already supports hardware-based keys via existing interfaces.

mjg59 4y ago
Not directly - you can use CryptoTokenKit to bind SE keys into the keychain as if they were a smartcard, but there's no shipped tooling for that.

rgreen 4y ago

Secretive is one of my favorite tools on mac os. it's the best ssh workflow i've used: key material never leaves the device, can auth with touch id, and forward the agent as necessary. i've also sent him $ on github as a small thank you for a tool i use daily (and i'd encourage you to, too!)