This page walks through loading keys into a Yubikey. (I wrote the page with the assumption that the user is using Tails for this, since the only place I keep copies of my secret keys is on a Tails “persistent disk”.)
The Yubikey’s GPG app emulates a PGPCard device. PGPCard is an open standard for storing PGP keys on a smartcard. The GnuPG software uses something like pcscd to talk to the PGPCard hardware.
gpg-agent is configured to speak the same protocol as ssh-agent, in addition to the standard PGP agent protocol. It satisfies SSH challenges by passing them along to the GPG app on the smartcard (i.e. the Yubikey). The secret keys involved never leave the Yubikey.
The SSH_AUTH_SOCK variable points to a named pipe where gpg-agent is listening, rather than the named pipe that ssh-agent listens on. The client (i.e. ssh, scp, etc.) doesn’t know or care that pgp-agent is being used.
This page explains how to configure a workstation to use SSH keys stored on a Yubikey. It has directions for macOS, RedHat/CentOS, and Debian, however to be honest the Debian directions aren’t as well-tested as the others.
I do this with all of my workstations, and there are commands that can be run to temporarily use my SSH keys from other machines (where I’m able to physically plug in a Yubikey), without any danger of the secret keys being recoverable by the owners of those machines. When I unplug the Yubikey, the secret key is immediately un-usable.
I do not like that you can’t have multiple ssh keys in that case as I like to have separated envs for different purposes (have no idea why, just like the vibe)
You can have multiple SSH keys if you want. They can be stored on different Yubikey devices, and whichever Yubikeys are plugged in, the authentication keys stored on those Yubikeys will be available for use with SSH connections. With two Yubikeys plugged in …
In addition, if you have secret key files on disk, you can use ssh-add to read them into the pgp-agent process. When you do this, pgp-agent re-encrypts the key (with the same or a different passphrase) and stores it under the $HOME/.gnupg/private-keys-v1.d/ directory, encrypted with the new passphrase.
Note that if you do this, those keys will be in gpg-agent forever, and ssh-add -d will not remove them. To remove them, you need to edit $HOME/.gnupg/sshcontrol and remove them from the list, and also remove the file under $HOME/.gnupg/private-keys-v1.d/ containing the secret key (the filename will be the “key grip”, which is the value you’ll see in the sshcontrol file). (I just added an item on my TODO list to add this information to the jms1.info site.)
A strange issue. I’m simply trying to move the desktop bin more onto the corner. I left-click and drag, all good so far. Yet whatever I do it won’t drop the bin and stays attached to the mouse cursor !?. I’ve even seen two bins. Only way out is switch off…
Is it me or does Trixie have a problem with changing locale @Rex ?
I’m in the UK. All was fine till I had wifi speed issues and mistakingly though it was a locale/local law issue so via ‘Control Centre’ I set my location to UK. Made no difference as the WiFi simply had power saving enabled.
Then I had trouble installing AIOv2_ctl. Errors occured in the .py install script that were related to US-UTF-8. I installed by removing those script errors (UTF-8 characters in 3 printf lines). Then checking my Btop monitoring tool I found it had stopped working due to the same UTF-8 issue. Changing back to US UTF-8 did not fix the issue even after reboot, neither did removing and reinstalling Btop (sudo apt purge). Now some new software installs complain that some locale setting files are missing, hence fail too. Error such as…
Locale: cannot set LC_CTYPE to default locale: no such file or directory
Yet looking in etc/default/locale it shows : #lang=en_US.UTF-8
Still I get install errors such as…
Perl:warning: cannot set locale
Locale: cannot set LC_CTYPE to default locale: no such file or directory
. Tried rebooting too…