It's not like non-technical people understand asymmetric cryptography. Or even technical people, for that matter.
Maybe we should refer to the public key as an address, and the private key is just a password again. You can send stuff, securely, to an address. And you can verify the sender when you have their address (ie check the signature).
The public counterpart is tricky to name but I think attaching "public" to it makes the intended usage plenty clear. There isn't really a physical counterpart unless you consider maybe those machines that check for counterfeit cash but even that's not a great fit because the pubkey is simultaneously analogous to a lock box.
It is true that publishing your private key is bad but you'd hope the name makes that pretty clear. Despite the way I remember (U2's "The Fly" lyrics, "A secret is something that you tell one other person, so I'm telling you, child") people generally do not understand that the whole point of secrets is that at least two parties know, which means you might always be betrayed by somebody you think is keeping your secret. For a private key it's easy, don't tell anybody, nobody knows, you can't be betrayed, done.
For example Hacker News learns my password to this web site every single time I sign in because that's just a secret. We've known how to do better for decades but only a handful of systems I use (e.g. Google) do so and all of them have a "traditional" password option which is like discovering your aeroplane still has a smoking section in 2026.
I don’t think there’s any process or entity in the physical world that is reasonably familiar to most people that is even remotely suitable as an analogy to public key cryptography.
These are not analogs to things ordinary people had already seen. For Computation we just got used to it being everywhere and so we don't need to explain it so much.
- If you install such keys to a host, and an attacker (with access to said host) has catalogued your ssh keys, they can see that you have access to said host (if they can correlate your method of publishing the keys to your identity)
On the other hand, if you go to the other extreme (?), you can have a different public ssh key per host. This way the server owner/attacker is not able to correlate that ssh key with other keys to recover your identity. (You need to take care that ssh won't offer too many public keys in that case.) Example case of a service that might get offered many ssh keys: github.
Personally I don't bother. But I wouldn't be too bothered about just putting my public keys to some "secret" URL in the internet either, so I can easily enable myself ssh access to a host with a single curl.. Maybe I should indeed do that.
A single Security Key can authenticate to Facebook as WeedLover420 and then be used to sign into the Google account of the Secretary of the US Marijuana Task Force and even if both Facebook and Google were co-operating in the work there's no way to connect these authentications. Obviously WeedLover420 is more likely to get caught because they used the same IP address to do both things and they stink of weed and they look stoned all the time, but none of those are because of the Security Key, that was locked down good.
> These are public keys, which are meant to be published - recovering one lets anyone check a signature, not forge one.