commit adb9166f22b506b4252dcc1b5fe015dd73fd9999
parent c0b02e8af52ee22c7289bf80bf9170f9d6f47e02
Author: pyratebeard <root@pyratebeard.net>
Date: Mon, 28 Nov 2022 16:43:29 +0000
Merge remote-tracking branch 'refs/remotes/origin/where_the_sshadows_lie' into where_the_sshadows_lie
Diffstat:
1 file changed, 20 insertions(+), 5 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,20 +6,35 @@ 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.
To get an idea of how others work I put out [a poll](TK){target="_blank" rel="noreferrer"} on Mastodon.
-
+
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. 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.
+
+To add your SSH key as a subkey edit your GPG key in expert mode
+```
+gpg2 -a --export-secret-keys <key_id> > gpg_key.asc
+mkdir tmp_gpg
+chmod 700 tmp_gpg
+gpg2 --homedir tmp_gpg --import gpg_key.asc
+```
+https://opensource.com/article/19/4/gpg-subkeys-ssh-multiples
+https://gist.github.com/grenade/6318301?permalink_comment_id=3527964
+https://unix.stackexchange.com/questions/372879/import-my-ssh-key-as-gpg-sub-key-to-use-for-ssh-authentication
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.
