6 ms·

This is about being able to connect keys to individuals and then searching The Stash for more links that then build a graph. But it's just metadata, isn't it..

the8472 11y ago
If you use a key exclusively for github servers then there's no graph-building. something like the following in ~/.ssh/config Host *.github.com IdentitiesOnly yes IdentityFile ~/.ssh/hostboundkeys/github_ed25519
- kardos 11y ago
  This is the answer right here. Also it's wise to use different keys for different services, for the same reasons that you'd use different passwords.
  - robryk 11y ago
    When I share a password between two services, they get the plaintext password when I authenticate, so the first one can impersonate me in front of the second one. How does this apply to keys?
    - kardos 11y ago
      If you have one key, and use it for N services, compromising your key compromises N accounts. If you use one key per service, compromising a key only compromises one account.
      - c22 11y ago
        And unlike passwords the extra overhead of maintaining multiple keys is virtually frictionless.
      - agwa 11y ago
        If you have your N private keys all stored on the same device (such as side-by-side in your ~/.ssh/keys directory, as in ryan-c's example upthread), under what scenario would just one of those keys get compromised? You only need one private key per device to be secure. The benefit of using separate keys per service is privacy - it prevents the various service providers from colluding to determine that you're a user of all the services (but if you're not careful you're probably leaking other information to them that would let them learn this anyways).
        kardos 11y ago
        If you're not using passphrases on your keys, then yes they are locally wide open, much like a passwords.txt strategy for passwords. If you do passphrase them, the attacker now needs N passphrases. Perhaps you notice the keylogger before all passphrases get logged? There are probably more scenarios where N keys is strictly better than one, but that's the first that comes to mind. I agree with the privacy aspect, it's that's the same point that the8472 made.
        Dylan16807 11y ago
        "perhaps you don't use password manager and you notice the keylogger halfway through" is a pretty unlikely scenario to motivate me to use a bunch of unique passphrases. It's not "strictly better" when it hurts your ability to use and memorize strong passes. Usability is part of security.
- ryan-c 11y ago
  Here's what I do: # IdentityFile magic, should be placed at very end of file Host * IdentityFile ~/.ssh/keys/id_ecdsa_%r@%h IdentityFile ~/.ssh/keys/id_rsa_%r@%h IdentityFile ~/.ssh/keys/id_ecdsa_ANY@%h IdentityFile ~/.ssh/keys/id_rsa_ANY@%h IdentityFile ~/.ssh/keys/id_ecdsa_%r@ANY IdentityFile ~/.ssh/keys/id_rsa_%r@ANY IdentityFile ~/.ssh/keys/id_ecdsa_ANY@ANY IdentityFile ~/.ssh/keys/id_rsa_ANY@ANY Will look for user@host, ANY@host, user@ANY, then ANY@ANY keys. You can add ed25519 to this.
  - shabble 11y ago
    This looks pretty neat -- however, do you use passphrases for your keys, and if so, how do you manage them? Only 2 obvious solutions spring immediately to mind - use the same (or none) pass for each key, or have a unique one per-key and some sort of separate password database with a master password. At least, I can't imagine memorising enough unique passphrases for all the user/host combinations I currently have. I'm hoping there's some clever built-in or easily added (like keychain/agent) way to secure individual keys on the filesystem without excess complexity when using them.
    - ryan-c 11y ago
      The IdentifyFile directives actually work with ssh-agent - it will try the keys listed there first, using them via the agent if they're loaded. I use the same passphrase on all keys and load them into my agent all at once (when loading, the last passphrase you entered will be tried to decrypt each key). Normally, the problem with having many keys in the agent is that a server you're logging into will boot you after supplying too many keys it doesn't accept, but this fixes that.

the8472 11y ago

If you use a key exclusively for github servers then there's no graph-building. something like the following in ~/.ssh/config Host *.github.com IdentitiesOnly yes IdentityFile ~/.ssh/hostboundkeys/github_ed25519

kardos 11y ago
This is the answer right here. Also it's wise to use different keys for different services, for the same reasons that you'd use different passwords.
- robryk 11y ago
  When I share a password between two services, they get the plaintext password when I authenticate, so the first one can impersonate me in front of the second one. How does this apply to keys?
  - kardos 11y ago
    If you have one key, and use it for N services, compromising your key compromises N accounts. If you use one key per service, compromising a key only compromises one account.
    - c22 11y ago
      And unlike passwords the extra overhead of maintaining multiple keys is virtually frictionless.
    - agwa 11y ago
      If you have your N private keys all stored on the same device (such as side-by-side in your ~/.ssh/keys directory, as in ryan-c's example upthread), under what scenario would just one of those keys get compromised? You only need one private key per device to be secure. The benefit of using separate keys per service is privacy - it prevents the various service providers from colluding to determine that you're a user of all the services (but if you're not careful you're probably leaking other information to them that would let them learn this anyways).
      - kardos 11y ago
        If you're not using passphrases on your keys, then yes they are locally wide open, much like a passwords.txt strategy for passwords. If you do passphrase them, the attacker now needs N passphrases. Perhaps you notice the keylogger before all passphrases get logged? There are probably more scenarios where N keys is strictly better than one, but that's the first that comes to mind. I agree with the privacy aspect, it's that's the same point that the8472 made.
        Dylan16807 11y ago
        "perhaps you don't use password manager and you notice the keylogger halfway through" is a pretty unlikely scenario to motivate me to use a bunch of unique passphrases. It's not "strictly better" when it hurts your ability to use and memorize strong passes. Usability is part of security.
ryan-c 11y ago
Here's what I do: # IdentityFile magic, should be placed at very end of file Host * IdentityFile ~/.ssh/keys/id_ecdsa_%r@%h IdentityFile ~/.ssh/keys/id_rsa_%r@%h IdentityFile ~/.ssh/keys/id_ecdsa_ANY@%h IdentityFile ~/.ssh/keys/id_rsa_ANY@%h IdentityFile ~/.ssh/keys/id_ecdsa_%r@ANY IdentityFile ~/.ssh/keys/id_rsa_%r@ANY IdentityFile ~/.ssh/keys/id_ecdsa_ANY@ANY IdentityFile ~/.ssh/keys/id_rsa_ANY@ANY Will look for user@host, ANY@host, user@ANY, then ANY@ANY keys. You can add ed25519 to this.
- shabble 11y ago
  This looks pretty neat -- however, do you use passphrases for your keys, and if so, how do you manage them? Only 2 obvious solutions spring immediately to mind - use the same (or none) pass for each key, or have a unique one per-key and some sort of separate password database with a master password. At least, I can't imagine memorising enough unique passphrases for all the user/host combinations I currently have. I'm hoping there's some clever built-in or easily added (like keychain/agent) way to secure individual keys on the filesystem without excess complexity when using them.
  - ryan-c 11y ago
    The IdentifyFile directives actually work with ssh-agent - it will try the keys listed there first, using them via the agent if they're loaded. I use the same passphrase on all keys and load them into my agent all at once (when loading, the last passphrase you entered will be tried to decrypt each key). Normally, the problem with having many keys in the agent is that a server you're logging into will boot you after supplying too many keys it doesn't accept, but this fixes that.