commit 5c170158df2b265903e06dcf893e8d260f24cb2d
parent a3844eeb9c80507debef270e5c1c707a2887e0c8
Author: pyratebeard <root@pyratebeard.net>
Date: Mon, 21 Nov 2022 22:11:20 +0000
where_the_sshadows_lie
Diffstat:
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/entry/where_the_sshadows_lie.md b/entry/where_the_sshadows_lie.md
@@ -1,4 +1,4 @@
-For as long as I can remember I have used one SSH key pair for each device. I know there are some who prefer to use a different key for different accounts as well. I tried this in the past but felt it didn't increase the security sufficiently enough to warrant the complexity in my use case.
+For as long as I can remember I have used one SSH key pair for each device. I know there are some who prefer to use a different key for different accounts. I tried this in the past but felt it didn't increase the security sufficiently enough to warrant the complexity in my use case.
I have three main devices; my desktop PC, my laptop, and my phone. This means that any system I need to `ssh` on to requires three entries in the *authorized_keys* file.
@@ -6,7 +6,7 @@ I use `drist` for ensuring my keys are on my servers (see a [previous post](TK){
When I rebuilt my laptop recently I generated a new key pair, then updated my drist configuration and pushed it out to my systems. All was well until I wanted to connect to my account on [sdf.org](https://sdf.org){target="_blank" rel="noreferrer"}, and realised I had not pushed the updated public key for my laptop to my SDF account.
-This got me thinking about alternative ways of SSH key management. With regards to a GPG key, we usually create one key that belongs to our identity. In my case [my key](TK){target="_blank" rel="noreferrer"} is used with my email, git commit signing, and other encryption to prove I am pyratebeard. The private key has been securely copied to my laptop and phone and imported into the GPG keyring.
+This got me thinking. For those that use a GPG key, it is very common to have one key that belongs to an identity. In my case [my key](TK){target="_blank" rel="noreferrer"} is used with my email, git commit signing, and other encryption to prove I am pyratebeard. The private key has been securely copied to my laptop and phone and imported into the GPG keyring.
Could one SSH key pair for _my identity_ be enough? If the private key was securely copied to my devices, then my systems and any accounts that require `ssh` only need to know about one key.
@@ -18,8 +18,15 @@ It surprised me that an equal number of people use one key per device as those t
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. 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"..
+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.
+As it turns out you can add an SSH key as a subkey 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"}.
+
+During my research I was also reminded of [SSH certificates](TK){target="_blank" rel="noreferrer"} and their advantages over key pairs. I am going to delve into that with my own systems (expect a write up!) but it doesn't help on systems I do not control, such as SDF.
+
+The SSH subkey is working well so far, and I am still tempted with a hardware key.
