SSH Key Management

edited February 21 in Help

Question! What do you all use for SSH Key management? I find keeping track of them all to be getting a bit much, lol.

And possibly related, do you generate individual key pairs for every client-server? Like for example, let's say I have two computers I use to access different servers sometimes. Let's say I have 5 servers. Should I do something like:

Server1 gets Key A from computer 1 and Key B from computer 2
Server2, Server3, Server4, and Server 5 all get the same Key A and the same Key B

i.e. one key per computer, given to all servers that computer accesses, making 2 total keys.

Or do you do something like this:

Server1 gets Key A-1 from computer 1 and Key B-1 from computer 2
Server2 gets Key A-2 from computer 1 and Key B-2 from computer 2
Server3 gets Key A-3 from computer 1 and Key B-3 from computer 2
Server4 gets Key A-4 from computer 1 and Key B-4 from computer 2
Server5 gets Key A-5 from computer 1 and Key B-5 from computer 2

i.e. each computer-server pair has its own key pair generated, making 10 total keys.

I ask because the first is what I've been doing, but it seems like the second would be more secure. But the second would also be a ton more work, especially as things scale higher, and I just do this for a fun hobby and minor utility, not a job, lol.

Comments

  • While I only have one computer, I also only have one key (used with 20+ servers), and I don't really see any security benefits of method 2. The only thing I would consider important (what you are already doing in method 1) is to use different keys for different computers.

    Thanked by (1)vr10

    cpu_logger | Recommended providers: Layer7, dataforest (Avoro/PHP-Friends), @host_c

  • this is all insane.

    put it in 1password and use the same user key everywhere.

    add SSH host key signing to your Ansible or whatever config and have every server get a signed key so clients don't complain, and inject your pub key on to each machine at provisioning time so you don't ever need a password.

    Thanked by (1)Multi_
  • @lukast__ said:
    While I only have one computer, I also only have one key (used with 20+ servers), and I don't really see any security benefits of method 2. The only thing I would consider important (what you are already doing in method 1) is to use different keys for different computers.

    I don't see any benefit in the second method too. Most probably won't use a passphrase on the ssh key so incase one key gets stolen through malware all of them are compromised anyway. You would need to use a different passphrase on all of them and don't save the passphrase in a password manager.

    Personally I am using only a single key for both my computer and my notebook which I save in 1Password (afaik Bitwarden does offer a similar feature).

  • AuroraZeroAuroraZero ModeratorHosting ProviderRetired

    @lukast__ said:
    While I only have one computer, I also only have one key (used with 20+ servers), and I don't really see any security benefits of method 2. The only thing I would consider important (what you are already doing in method 1) is to use different keys for different computers.

    There is no security benefits. One key to rule them all is the way to go.

  • edited February 21

    I use KeePassXC with SSH Agent integration, it works great.

    @AuroraZero said: There is no security benefits. One key to rule them all is the way to go.

    There is a privacy benefit, you don't want to leave your pubkey everywhere. I prefer to have separated keys for different tasks.

  • So if I'm understanding, most of you are in the following hypothetical scenario:

    Server1 gets Key A from computer 1 which gets copied to computer 2 as well
    Server2, Server3, Server4, Server5 all also get Key A.

    i.e. one single keypair, so the same single pubkey on all servers and the originally generated private key on any computer I'm accessing them from?

  • @SocksAreComfortable said:
    So if I'm understanding, most of you are in the following hypothetical scenario:

    Server1 gets Key A from computer 1 which gets copied to computer 2 as well
    Server2, Server3, Server4, Server5 all also get Key A.

    i.e. one single keypair, so the same single pubkey on all servers and the originally generated private key on any computer I'm accessing them from?

    I think each client/ computer should be its own key pair.

    So 5 clients u use, 5 public keys copied on all servers.
    In that way you don't need to move around and risk exposing the private key.

  • @localhost said:

    @SocksAreComfortable said:
    So if I'm understanding, most of you are in the following hypothetical scenario:

    Server1 gets Key A from computer 1 which gets copied to computer 2 as well
    Server2, Server3, Server4, Server5 all also get Key A.

    i.e. one single keypair, so the same single pubkey on all servers and the originally generated private key on any computer I'm accessing them from?

    I think each client/ computer should be its own key pair.

    So 5 clients u use, 5 public keys copied on all servers.
    In that way you don't need to move around and risk exposing the private key.

    Agreed, each client machine has its own key pair and the private key never leaves that machine.

  • Each server has a unique host key.
    Some templates have a built-in host key, which is insecure.
    When we have to use a template, we delete the existing host keys and generate new ones.

    Each mobile client (any device that can be taken outside the house) has a unique private key.
    The corresponding public keys are authorized on a gateway device in the house.
    The device is currently a BeagleBone Black, 12-year old but still operational.

    The gateway device and all desktop computers share the same private key.
    The corresponding public keys are authorized on all the servers.

    If we obtain a new mobile device, we insert its public key in the gateway device.
    If we sell a mobile device, we delete its public key from the gateway device.

    No hostname left!

Sign In or Register to comment.