5 ms·

Is there any case where they ever need to be shared? If you need a login, generate a new one.

by mr_toad 1y ago

chrisweekly 1y ago
Yeah, I'd strike "except where they're needed". Never share a private key.
- IgorPartola 1y ago
  One of the best things you can do is generate a key per device, not per person. That way if you lose your phone you just revoke that key and not the one that you use on your tablet, work laptop, home desktop, etc. Bonus points: monkeysphere and certificate based auth are two other great solutions for making sure the ssh server you log into is not doing a MITM on initial connection (you know, the part where it asks you to manually verify the fingerprint of the server key and you likely just hit y instead). Forwarding your ssh agent to a host that you don’t know for certain is not doing a MITM attack on you can be devastating, as is entering a password into same.
  - munchler 1y ago
    But that way you can only use each key on that one device. E.g. No starting a private conversation on your phone and then continuing it on your desktop later.
    - IgorPartola 1y ago
      The service you use should allow you to add more than one key and create a symmetric encryption key for the conversion. Your private key identifies your device, the service should know that you own multiple devices.
  - msgodel 1y ago
    Are there really people who don't do this? Copying private keys around just feels gross like copying binaries around.
nisegami 1y ago
My company's system admins don't know how to do that unfortunately.
- bornfreddy 1y ago
  No worries, I'm sure there are lots of webpages that will generate private keys for them. For free.
hinkley 1y ago
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.
uniqueusername7 1y ago
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.
- mr_toad 1y ago
  Generate a new private/public key pair on the new machine and then copy the public key (from the new machine) into the authorised keys (on the server) using a login that already has access (e.g. from the old machine).

Is there any case where they ever need to be shared? If you need a login, generate a new one.

chrisweekly 1y ago

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

IgorPartola 1y ago
One of the best things you can do is generate a key per device, not per person. That way if you lose your phone you just revoke that key and not the one that you use on your tablet, work laptop, home desktop, etc. Bonus points: monkeysphere and certificate based auth are two other great solutions for making sure the ssh server you log into is not doing a MITM on initial connection (you know, the part where it asks you to manually verify the fingerprint of the server key and you likely just hit y instead). Forwarding your ssh agent to a host that you don’t know for certain is not doing a MITM attack on you can be devastating, as is entering a password into same.
- munchler 1y ago
  But that way you can only use each key on that one device. E.g. No starting a private conversation on your phone and then continuing it on your desktop later.
  - IgorPartola 1y ago
    The service you use should allow you to add more than one key and create a symmetric encryption key for the conversion. Your private key identifies your device, the service should know that you own multiple devices.
- msgodel 1y ago
  Are there really people who don't do this? Copying private keys around just feels gross like copying binaries around.

nisegami 1y ago

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

bornfreddy 1y ago
No worries, I'm sure there are lots of webpages that will generate private keys for them. For free.

hinkley 1y ago

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.

uniqueusername7 1y ago

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.

mr_toad 1y ago
Generate a new private/public key pair on the new machine and then copy the public key (from the new machine) into the authorised keys (on the server) using a login that already has access (e.g. from the old machine).