commit a5858b1e4a20abed069aa6cb9bd454cdaf139c36
parent 71f4904b57e5435183426e621f1c531bdb6cdb28
Author: pyratebeard <root@pyratebeard.net>
Date: Fri, 2 Dec 2022 08:59:35 +0000
where_the_sshadows_lie
Diffstat:
1 file changed, 20 insertions(+), 8 deletions(-)
diff --git a/entry/where_the_sshadows_lie.md b/entry/where_the_sshadows_lie.md
@@ -4,7 +4,7 @@ I have three main devices; my desktop PC, my laptop, and my phone. This means t
I use `drist` for ensuring my keys are on my servers (see a [previous post](TK){target="_blank" rel="noreferrer"} about this tool), meaning I can connect from any of my devices.
-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.
+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. 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.
@@ -20,7 +20,7 @@ Maybe using one key isn't such a bad idea. Of course this changes my threat mod
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 as a subkey to a GPG key, then `gpg-agent` will provide the authentication instead of `ssh-agent`, and more importantly you don't need a SSH private key file.
+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 don't need an SSH private key file.
At first I attempted to add my existing SSH key to my GPG key, but hit a few blocks and started down a rabbit hole. Instead I opted to create a new SSH key. This would mean I would have to push it out to everywhere I needed it, a small price for ease of setting up.
@@ -39,18 +39,18 @@ Now is a good time to take the new SSH public key and copy it everywhere you nee
gpg2 --export-ssh-key <key_id>
```
-Next we can stop our `ssh-agent` and `gpg-agent`. I use [keychain](TK) for managing my agents
+Next we can stop our `ssh-agent` and `gpg-agent`. I use [keychain](TK) for managing my agents so incant
```
keychain --agents ssh,gpg -k
```
-We have to tell GPG which subkey to use for SSH, wedo this by taking the _keygrip_ and putting it into GPG's _sshcontrol_ file
+We have to tell GPG which subkey to use for SSH, we do this by taking the _keygrip_ and putting it into GPG's _sshcontrol_ file
```
gpg2 -k --with-keygrip <key_id>
echo <keygrip> >> ~/.gnupg/sshcontrol
```
-Now to start the `gpg-agent` back up, no `ssh-agent` required. In my `zsh` config I modified the `keychain` command to remove the option to start `ssh-agent`. I also added a `gpg-connect-agent` command to TK, then set the `SSH_AUTH_SOCK` variable
+Now to start the `gpg-agent` back up, no `ssh-agent` required. In my `zsh` config I modified the `keychain` command to remove the option to start `ssh-agent`. I then set the `SSH_AUTH_SOCK` variable
```
eval $(keychain -q --agents gpg --nogui --eval 0xC7877C715113A16D)
gpg-connect-agent updatestartuptty /bye >/dev/null
@@ -58,12 +58,24 @@ if [ "${gnupg_SSH_AUTH_SOCK_by:-0}" -ne $$ ] ; then
export SSH_AUTH_SOCK="$(gpgconf --list-dirs agent-ssh-socket)"
fi
```
+
+You can also see a `gpg-connect-agent` command in there. This is used to tell GPG to update the TTY it is using. GPG has no way of knowing which TTY you are using, so when it requires `pinentry` it needs to know which TTY to listen for user interaction. You could avoid this by using `pinentry` with a GUI.
+
+Now if you open a new terminal, or source your config, SSH should work using your GPG key. You will be prompted to enter a passphrase with the first connection, this is the same as your GPG passphrase.
+
+Now you can copy your updated GPG key to your other devices (you may need to delete the existing key before importing)
```
gpg2 -a --export-secret-keys <key_id> > gpg_with_ssh.asc
```
-Going one step further took [me back](TK){target="_blank" rel="noreferrer"} to hardware keys such as the [Yubikey](TK){target="_blank" rel="noreferrer"}.
+The SSH subkey is working okay so far. I am using it on my desktop (running Arch Linux), my laptop (running OpenBSD), and with [Termux](TK){target="_blank" rel="noreferrer"} on my phone.
-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.
+There have been a few issues though, hopefully easily fixed with a bit of investigating. On Termux I am not prompted for my GPG passphrase when I first start a session. Maybe this is something to do with how `keychain` works on Termux. I also noticed that if I have two `tmux` windows I need to rerun the `gpg-connect-agent` command otherwise `pinentry` may startup on the other window.
-The SSH subkey is working well so far, and I am still tempted with a hardware key.
+On OpenBSD `pinentry` seems to crash `tmux`. This is my first OpenBSD install as a workstation so I am still figuring things out.
+
+The `gpg-connect-agent` command has to be run again sometimes. After using `git commit` it seems to need to be run before SSH will work.
+
+and I am still tempted with a hardware key.
+
+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.
