commit a3844eeb9c80507debef270e5c1c707a2887e0c8
parent ad71e0e08b80c6c9e49d477da739b305e95c9ac8
Author: pyratebeard <root@pyratebeard.net>
Date: Wed, 16 Nov 2022 19:05:30 +0000
where_the_sshadows_lie
Diffstat:
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/entry/where_the_sshadows_lie.md b/entry/where_the_sshadows_lie.md
@@ -14,11 +14,12 @@ To get an idea of how others work I put out [a poll](TK){target="_blank" rel="no
![results](/img/sshkey_poll.png#fitwidth)
-It surprised me that an equal number of people use one key per device, and one key for all.
+It surprised me that an equal number of people use one key per device as those that use one key for all.
Maybe using one key isn't such a bad idea. Of course this changes my threat model. If any of my devices are compromised I would have to replace the key on all of them.
-When a GPG key is loaded into your keyring you don't have to keep the private key. With SSH keys there is no keyring, `ssh` uses the private key file when connecting. There is of course `ssh-agent` which can load the key in memory, but the private key still has to be read after a reboot. This isn't ideal, so I went looking for a more secure way.
+When a GPG key is loaded into your keyring you don't have to keep the private key. With SSH keys there is no keyring, `ssh` uses the private key file when connecting. There is of course `ssh-agent` which can load the key in memory, but the private key still has to be read after a reboot. The key will still need a passphrase to be used, just like using your GPG key still requires a passphrase, but something about having the GPG key in a keybox file seems more secure than the SSH key "just lying around"..
As it turns out you can add an SSH key to a GPG key then `gpg-agent` will provide the authentication instead of `ssh-agent`, and more importantly you can delete you SSH private key.
+Going one step further took [me back](TK){target="_blank" rel="noreferrer"} to hardware keys such as the [Yubikey](TK){target="_blank" rel="noreferrer"}.