[thaumasiotes]

Yes, but there's a reason those are called "public" keys. The reason is that you don't suffer any harm by giving them out.

Except that they may be publicly identified with you. In that case, and only that case, giving them out would involve purporting to be the person who is publicly associated with the keys. (It wouldn't prove it, because, after all, those keys are public; anyone can know and distribute them.)

So this concern appears to be that you want to apply for a job without disclosing your identity. I think that's a strange thing to do.

[morpheuskafka]

The other reply to this comment misses the fact that an nonce is used in the client authentication process. Thus, one server to which you successfully authenticate using a public key cannot replay that against a different server that accepts the same key. There is a unique value that is sent to the client, hashed, and then signed with the private key.

Anyone can download your public SSH keys from GitHub (github.com/<username>.keys). The Ubuntu Server installed uses this to make setting up a mostly headless server easier.

[dasyatidprime]

If you mean geofft's comment, I don't believe they're talking about a replay attack. thaumasiotes wrote "It wouldn't prove it, because anyone could be presenting the public key", but geofft is saying that if the server claims to recognize the key and requests to continue authentication using it, then your client will potentially provide the proof—invisibly and automatically, if the private key is passwordless/agent-loaded. There is no second server; this is the original server being able to confirm that you are actually in possession of a supposedly-unrelated-to-anything key. (I have not verified whether the order of operations in the protocol actually works this way; I'm just interpreting what geofft is saying.)

[quickthrower2]

People can have multiple online identities. It’s like applying for a job and not giving your “fun” reddit username.

[geofft]

> (It wouldn't prove it, because, after all, those keys are public; anyone can know and distribute them.)

I don't believe this is true, right? You do a private key operation demonstrating you possess the private key associated with the public key.

Or, by contradiction: Since the key is public, any server can put the fingerprint of the key in an authorized_keys file. It can then challenge you to log in in a way that exactly matches what a real server you'd actually want to log into would do, because a real server doesn't have your private key either. If your client could also authenticate to the server in a way that didn't prove anything beyond possession of the public key, then it could do the same to some actual server, i.e., the SSH protocol would have no meaningful authentication at all. Because we know the SSH protocol is not completely and trivially broken, this cannot be true.

(I think you also overestimate the value of technical deniability - certainly outside a court of law, nobody is obligated to think, "Well, it could be a complete coincidence, so I'm going to disregard this piece of information I just learned." And I wouldn't bet on it inside a court of law either.)

[dumpsterdiver]

If I had two servers allowing ssh, and you logged into one of them by providing a public key which I added to the authorized_keys file, it would be a good guess that it was still you if you logged into my second server the same way.

Is that what you’re trying to say?

Granted it still wouldn’t prove it, because we are not our ssh keys. We’re all potentially one malware infection away from having our private keys compromised. Also, if someone wanted to "shed" the identity associated with a public key they could always just "accidentally" leak the private key in a public git commit.

[thaumasiotes]

> Also, if someone wanted to "shed" the identity associated with a public key they could always just "accidentally" leak the private key in a public git commit.

That would allow anyone to prove that they owned the public key, which prevents the original owner from using it. But it seems like, if you want to stop using the key, it's simpler to just stop using it. What does leaking the private key accomplish that deleting the private key doesn't also accomplish?

[dumpsterdiver]

Plausible deniability.

[thaumasiotes]

How?

[thaumasiotes]

> I think you also overestimate the value of technical deniability

Huh? I presented the claim to identity that submitting a public key implicitly makes as being the only thing that our hypothetical applicant is seeking to avoid. I valued the technical deniability at zero.

But I said above, and say again here, that most job applicants are not seeking to avoid disclosing their identity as they apply for a job. They are usually specifically trying to highlight it.

[thewakalix]

As I understand it, your SSH client gives out all your public keys, but doesn’t authenticate with all of them. That might be the crux.

[dasyatidprime]

I would say more specifically: if you have any SSH keys that are associated with non-career nyms (which is a perfectly reasonable thing to do) then keep them separate and only include them for known associated hosts, perhaps by using IdentityFile in Host blocks in .ssh/config.

[parksy]

I think the OP's service is pretty cool, it reminds me of ye olde BBS's. I am actually writing my personal resume as a command prompt based on old 80's PCs as well, albeit in HTML/JS, so I do dig the aesthetic.

Application-wise: The statement "In case you want to apply for a job without admitting who you are" is begging the question that the service is actually for job applications, something we have no trust in or knowledge of other than the title of a post on a public forum.

Identity-wise: You're also making the assumption that key = person. Keys can be set up to authenticate client applications and remote services with each other. People can have dozens of keys for various things they have installed via wizards or copy-pasting tutorials which they may not even be aware of. Key pairs are also shared by email and internal docs far more often than they should be with limited control over who they are distributed to.

Harm-wise: If I were an evildoer, I would have spent my career obtaining and organising databases full of all sorts of information; email addresses, hashed passwords, usernames / aliases, phone numbers, etc. I'd definitely have a special database set aside for key-pairs I've scraped from various plaintext sources that I haven't found a use for. The opportunity to target a subset of industry professionals (with presumably more privileged access to information than the average joe) to correlate even a small fraction of known public keys with specific IPs, email addresses, even hackernews aliases would be a huge value add to my "services". You could just slurp the data in, then even if you get no hits, maybe a year or two down the line it becomes relevant.

For anyone dealing with this kind of threat vector on the daily the stakes are pretty high and can include bankruptcy and professional ruin. Yeah we all visit random websites, but it's not every day people connect to an SSH server outside of their trust network. Do you really wanna be that guy whose key was used to leak a database full of medical data or something?

The audience of this website include people who work with PII and may not be familiar with the intricacies of the SSH command line utility, and the state of affairs in information security is pretty bleak in IT-backed organisations as we see every single day, so in this context I don't think it's cool to bash people being privacy conscious.