That is not necessarily an oversight, the issue is that communication between gpg and pcscd and the smartcard is notoriously unreliable nowadays. Usually restarting pcscd a couple of times helps.
If its the Yubikey challenge-response, you can’t forward that as far as I know.
If you want to encrypt/decrypt remotely with GPG, this is the simple, reliable guide to follow: GPG Agent Forwarding - Matthias Lohr. That will show how to forward the gpg socket over SSH. I use this on NixOS with other NixOS hosts and non-NixOS hosts. If you use gpgconf remotely and locally to determine the right paths, things tend “to work”.
SSH connection using gpg-agent and key created and stored into yubikey (as smartcard) works
typing ssh-add -l on remote after connection works and return 4096 SHA256:xxx cardno:xxx (RSA)
BUT anything linked to detection of smartcard, like gpg --smart-status, gpg --card-edit don’t work, this is strange, no ?
drduh/YubiKey-Guide say, on the FWD agent part :
You should now be able use ssh -A remote on the local machine to log into remote , and should then be able to use YubiKey as if it were connected to the remote machine.
Perhaps the Yubikey challenge-response (configured on slot 2) cannot be FWD, but reading the drduh guide, it seems possible to access some smartcard functionalities during/on remote.
Edit : i try the tutorial mlohr (old way to do that, if i read correctly the drduh tutorial), using directly RemoteForward on command line -A -R, also without success :
ssh -A xxx -R /run/user/0/gnupg/S.gpg-agent:/run/user/1000/gnupg/S.gpg-agent
I don’t think the challenge-response protocol can be forwarded. Therefore the nixos setting boot.initrd.luks.devices.<name?>.yubikey will not work for you.
SSH and gnupg will work remotely due to agent forwarding (and I think this is what DrDuh is referring to). So you could possibly use GPG agent forwarding and the boot.initrd.luks.gpgSupport setting to unlock your encrypted disk.
--card-status and other card operations specifically don’t work over the extra socket meant for forwarding. See the error near the bottom here: Forwarding GPG over SSH | Alt255 Blog
On the remote, import your gpg public key, then check gpg --list-secret-keys and see if they’re loaded.
No, I’m sorry for any confusion; the smartcard can be used for decryption and encryption operations remotely. However, things like --card-status do not work. My gpg authentication key is used for SSH as well.
I did forget that I had the private key on this machine for that example, my mistake. But I assure you, it still works. I can show an example in a bit.
Yep, i have the same worflow, ssh-add -l show on remote that my smartcard is correctly fwd and ready to decrypt/encrypt … but the life is not so simple
I try to reproduce the end of your workflow in gist, the encrypt/decrypt part that i never test before…
But i first had some bug/problem (https://github.com/NixOS/nixpkgs/issues/72597) with gpg-agent pinentry not spawing in “ncurse” mode correctly with systemd (don’t know why) and now when i try to encrypt on remote …
gpg: WARNING: server 'gpg-agent' is older than us (2.2.12 < 2.2.20)
gpg: Note: Outdated servers may lack important security fixes.
gpg: Note: Use the command "gpgconf --kill all" to restart them.
gpg: problem with the agent: Forbidden
gpg: error creating passphrase: Operation cancelled
gpg: symmetric encryption of 'test.txt' failed: Operation cancelled
Edit, linked to pinentry
gpgconf --check-programs
gpgconf: error running '/nix/store/yvnd02rbdsin2waamh9kb94klipajbhi-gnupg-2.2.20/bin/pinentry': probably not installed
I install pinentry using configuration.nix, but path don’t correspond and gpg encrypt/decrypt continue to failed :
'/nix/store/aba4by40pyv40gd780px1ivcskdnsd1g-pinentry-1.1.0' from 'https://cache.nixos.org'...
Just another tip: SSH Agent forwarding is completely unrelated to forwarding the GPG Agent socket. ssh-add -l working on remote means nothing about GPG-agent forwarding.
Yes. I am using a very similar setup as that article. If you are trying to use GPG to decrypt a file on a remote host, SSH forwarding is completely uninvolved.
Interestingly, just last night, I was complaining about problems with gpg-agent where I had to reboot before pinentry would work. (But in that case, pinentry is being done locally, so if local encryption works, then remote should work once forwarding has been done properly.)
EDIT: to extend the demo I showed in the gist above, here I show me decrypting a file remotely WITHOUT -A, so you can see that the gpg forwarding is unrelated to ssh forwarding:
ssh -o "RemoteForward $rpath:$lpath" cole@192.168.1.155 gpg -d /tmp/test.txt.gpg
gpg: encrypted with 4096-bit RSA key, ID 0x62556A61E301DC21, created 2018-05-22
"Cole Mickens <cole.mickens@gmail.com>"
this is a test
