Can confirm

Very strange. I sent a test key and didn't get that response but when I sent my real key it did. How did it know the difference between the dummy key and the real key?

Yeah, I'd strike "except where they're needed". Never share a private key.

My company's system admins don't know how to do that unfortunately.

There is not. I worked on a code signing project, and there was this guy who I as already warned had a bit of Dunning Kruger going on, but would later discover was also a bit of an ineffectual bully as well, when he got into an argument with both me and a customer.

Not long after the first milestone of a project with lots of milestones he announced he intended to have me to generate ‘real’ keys for the project and send him the key pairs over Outlook Encryption. For a project with public safety concerns written all over it, and would later have me pick multiple Hardware Security Modules for different steps of a multi-signature chaining process.

He tried to get me into trouble for telling him, politely, that he could fuck right off. And then had to talk to everyone he tried to tattle to about why he was a dumbass and that we were at least a year (turned out to be three) before we needed “real” keys - we were actually about four months from even needing fake keys for integration testing, let alone real keys. And I was be writing up runbooks for doing that rather than doing it for people.

The thing I would soon discover about signing keys is that everyone thinks they are a magic incantation of math. They’re just math. The magic is not inside the box, the magic is the box. It’s like a clean room: It’s a room full of nothing. What makes it special is all the work you do trying to prevent something from happening to it.

I stayed on that project almost a year past where there was any code they needed me to write (except for one bad bug I would find in my code a few months later), but they still needed me to teach them behavior, to lock in that clean room mindset.

How would I get my ssh keys to the remote server from a new machine? To me, the easiest way seems to be either sharing private keys from a different machine, or having some way to deterministically generate keys from a password or keyphrase, and the latter seems more secure to me because I don't have to trust a middle man to do the transferring.

Assuming for the sake of argument this were a real service checking for matches, the chances of a hash collision with SHA256 is effectively 0.[1] I entered the limit for BIGINT (9223372036854775807), and the approximation of the probability of a hash collision after generating 9223372036854775807 items in SHA256 is zero. The exact probability would probably take eons to calculate, but it's vanishingly close to zero.

1. https://kevingal.com/apps/collision.html

Yeah reminds me of the time a real UK bank employee insisted that I should give him an SMS onetime code, even telling me to ignore the part of the message that I should never give the code to anyone else, not even a bank employee. I verified by other means that both he and the transaction were genuine but absolutely refused to give him that code no matter how he tried to spin it, and solved the issue a different way. Whatever manager created that ad hoc process needs to get fired.

The repo needs to be clean, but pre-built release binaries backdoored. It's classier this way.

Written in Rust or Go.