Hello guys
my hot photos are here ..
http://vivy.us/isxxx
username annaxx))
Secretive – macOS native app to store SSH keys in the Secure Enclave
51–60 of 109 posts
Re: Secretive – macOS native app to store SSH keys in the Secure Enclave
#52Earlier quoted context omitted.
Does it have touch to authorise (doesn't seem to support that), or is it just going to send on all of one's currently-loaded SSH keys whenever one connects with -A (seems to)? > You can configure your key so that they require Touch ID (or Watch) authentication before they're accessed. That, to me, would be a key thing to want to have: something that tells me "hey, Terminal just wanted to access your Github key. Is th…
After researching this for a while, it seems there is no documented, native option to do this. The only option is to unlock all SSH keys all the time, which makes them less secure than the passwords for websites managed by the exact same keychain. Which, in my opinion, is weird . Do they employees at Apple use a different system altogether? Because the built-in one doesn't seem very secure. Or maybe I am using it wro…
In regards to the ssh-agent stuff (and a lot of the other CLI tricks), the man pages usually document them. They may lag a bit for new features, but most of them will have a man page. Barring that they’ll usually print a help message.
One command off the top of my head that doesn’t really follow this is the undocumented/internal `airport` command. In that case it has two different help messages depending on how it’s called, and is also tucked away in a framework as well.
Re: Secretive – macOS native app to store SSH keys in the Secure Enclave
#53From the FAQ: > Q: How do I import my current SSH keys, or export my Secretive Keys? > A: The secure enclave doesn't allow import or export of private keys. For any new computer, you should just create a new set of keys. If you're using a smart card, you might be able to export your private key from the vendor's software. I don't get it. If so, how am I supposed to back up my keys in case of a hardware failure or har…
Like the others have said: You just use multiple. You can just add multiple keys to the authorized_keys file. This is actually the perfect scenario because an attacker can never get hold of the private key. That means that the key is unique: If it's in your hands, it means an attacker doesn't have it. Most smart cards work this way, they generate the private key inside and it can never leave the hardware, you can onl…
"now" is at least 16 years now (with PKCS11 and opensc)
Re: Secretive – macOS native app to store SSH keys in the Secure Enclave
#54For anyone interested in a standardised/Linux-compatible version of this, check out PKCS11 tokens. Smartcards can and do implement this spec, and if you use PKCS11, the secret is used from the token to sign an SSH login (for example), without being revealed. This means the secret itself stays on the card. You can combine this with certificates if needed; the smartcard handles the authentication. Using PKCS11 tokens i…
This works ok and is the best option at the moment, but as more systems upgrade to newer versions I think the Fido/U2F support is probably going to take over. It's nice to not have anything key specific, any initialization steps, and so on.
Edit: Maybe OpenSSH does offer resident keys. On the one hand their release notes say they do but on the other hand I was 100% sure somebody who should know insisted they didn't. A trawl of my records cannot find such a communication so perhaps I dreamt it. If resident keys are an option then you need to make sure to buy FIDO2 authenticators and to explicitly tell OpenSSH you want resident keys.
The current SSH FIDO behaviour doesn't do resident keys AFAIK. The OpenSSH team has discussed it, but not as I understand it written an implementation.
In a PIV setup Jim, Sarah and Gary can each have a device (say a Yubikey) with their own private key inside it. Both their workstations and shared desktop/ interactive servers can use these keys, when they're plugged in. So when Jim is sat at this workstation, Jim's key uses Jim's private key to authenticate Jim over SSH. If Sarah wants to use a machine she's never previously used, but it was set up for Jim and Gary, her key, Sarah's key, just works to authenticate as Sarah over SSH. Simple and easy to think about.
With FIDO non-resident keys a similar team Beth, Larry and Zoe have personal FIDO authenticators, let's say from Titan, they each set up their personal laptop to require their personal FIDO authenticator. Both elements are needed to authenticate. Beth's laptop, plus Beth's Titan key is enough to authenticate via SSH. But if Beth is at a Workstation she's never used before she can't use her Titan key to authenticate, it has no idea how to help on its own. If Beth sets that workstation up (a multi-step process) this isn't re-usable, Zoe can't use her Titan key without also going through that enrolment process.
The reason why is a mixture of differences between typical Web authentication journeys and SSH, and the deliberate (privacy preserving) feature paucity of FIDO Security Keys when used without resident keys.
The FIDO authenticator genuinely has no idea what your private key is (this is unlike for resident keys like Apple's recent announcement). It first needs to be presented with an ID, a large random-looking byte string. It has in fact encrypted your private key using AEAD mode with a secret symmetric key that's baked inside it and then used that as the ID. So when the ID comes back it decrypts it, the AEAD checks out, it now has a private key and can use that to authenticate you before it forgets it again.
On the Web in this case (again not the resident case like Apple's cool Safari feature) the ID is being delivered by a remote server to your web browser when you enter a username and the browser passes it to the FIDO authenticator. But in SSH authentication doesn't work that way.
So, OpenSSH stores the ID locally on a computer. It isn't secret, so it's not a huge deal if someone somehow steals it. But without that ID the authenticator can't do its job.
Maybe you could arrange to synchronise the IDs across machines in an organisation. But AFAIK nothing exists to sort that out today. So without either resident credentials (which need a more expensive FIDO2 authenticator) or some further synchronisation framework PIV is easier today if you want employees to authenticate from machines that aren't "their" personal machine.
Re: Secretive – macOS native app to store SSH keys in the Secure Enclave
#55A similar product that works on macs without a secure enclave by storing keys on the secure enclave of your iPhone is krypton. https://krypt.co/developers/
Been using this since the beginning and it’s great. However, there has been no updates ever since they were acquired by Akamai. A bit worried it’ll suddenly stop working one day...
Re: Secretive – macOS native app to store SSH keys in the Secure Enclave
#56For anyone not aware, you can use macOS's keychain to store ssh key passwords and have them unlock at login. This way you can have the benefits and convenience of password managers in the command line for SSH certificates. https://apple.stackexchange.com/questions/48502/how-can-i-pe...
Does it have touch to authorise (doesn't seem to support that), or is it just going to send on all of one's currently-loaded SSH keys whenever one connects with -A (seems to)? > You can configure your key so that they require Touch ID (or Watch) authentication before they're accessed. That, to me, would be a key thing to want to have: something that tells me "hey, Terminal just wanted to access your Github key. Is th…
My general understanding is that -A is generally discouraged in the first place: especially when connecting to an untrusted server. But, it just seems to me to be a bad idea to ever let a private key leave your computer. Instead, you should generate a key on the new box and authorize that one somehow (the lowest friction way would be to use an ssh ca to sign the key and then have the servers you want to log into trust only public keys that have been signed by the CA’s key.
Re: Secretive – macOS native app to store SSH keys in the Secure Enclave
#57Earlier quoted context omitted.
That's how language works. We call people "engineers" who have never and will never work on any engines.
engineer /ɛndʒɪˈnɪə/ Origin: "Middle English (denoting a designer and constructor of fortifications and weapons; formerly also as ingineer ): in early use from Old French engigneor, from medieval Latin ingeniator, from ingeniare ‘contrive, devise’, from Latin ingenium (see engine); in later use from French ingénieur or Italian ingegnere, also based on Latin ingenium, with the ending influenced by -eer."
This is also where the term 'civil engineer' comes from [1]. It was civilian-focused "engineering" of fortifications like bridges or roads. I've wondered for a while if there was any controversy around the first use of the term "electrical engineer" or "chemical engineer" like how there was with software engineering not being considered "real engineering" around 10 years ago, but I can't really find any information on that.
Re: Secretive – macOS native app to store SSH keys in the Secure Enclave
#58Earlier quoted context omitted.
If you only have a single SSH key as the only method of authenticating somewhere, you already have a dangerous single point of failure.
Not if you have multiple copies of the private key. But yes, there are advantages to having any given key only exist in one place.
If you are making multiple copies of a private key in different places, why wouldn't you just keep a different private key in each of those places along with its corresponding public key though?
That way, you can remove trust from just one of them if you (e.g.) have your computer stolen.
Re: Secretive – macOS native app to store SSH keys in the Secure Enclave
#59Does this mean that the Secure Enclave is accessible by the user? If so, it prompts so many questions. How much disk space is available on the Enclave, for example.
Totally a tangent, but it's interesting that we still refer to things as "disk space" even in the era of flash storage
Many words are like this. Music albums haven’t been actual albums for decades. Now we barely remember how a collection of songs was distributed as multiple shellac 78 RPM records stored in an album.
Re: Secretive – macOS native app to store SSH keys in the Secure Enclave
#60Earlier quoted context omitted.
Does it have touch to authorise (doesn't seem to support that), or is it just going to send on all of one's currently-loaded SSH keys whenever one connects with -A (seems to)? > You can configure your key so that they require Touch ID (or Watch) authentication before they're accessed. That, to me, would be a key thing to want to have: something that tells me "hey, Terminal just wanted to access your Github key. Is th…
My general understanding is that -A is generally discouraged in the first place: especially when connecting to an untrusted server. But, it just seems to me to be a bad idea to ever let a private key leave your computer. Instead, you should generate a key on the new box and authorize that one somehow (the lowest friction way would be to use an ssh ca to sign the key and then have the servers you want to log into trus…
-A does not forward your keys to the remote server itself; it "just" lets the remote server make requests to your local SSH agent to sign things. But you that's still sufficient to allow the remote server to sign into things as you without your authorization, so probably not the best of ideas to sign into servers you don't trust with -A.
If you're using -A to log into other machines behind the SSH server (really, the only reason one would use -A), there are now better mechanisms to do that. ProxyJump if the server supports it; port forwarding or ProxyCommand if it doesn't.