following.. which import paths are preferred?

$ go get -v filippo.io/yubikey-agent
go get filippo.io/yubikey-agent: unrecognized import path "filippo.io/yubikey-agent": reading https://filippo.io/yubikey-agent?go-get=1: 404 Not Found
 ~/go/src

$ go get -v github.com/FiloSottile/yubikey-agent
go: github.com/FiloSottile/yubikey-agent upgrade => v0.0.0-20200426062843-0096c094dcd2
go get: github.com/FiloSottile/[email protected]: parsing go.mod:
	module declares its path as: filippo.io/yubikey-agent
	        but was required as: github.com/FiloSottile/yubikey-agent

When using the SSH agent, it is possible to add a SSH certificate (https://smallstep.com/blog/use-ssh-certificates/) along with the corresponding private key file. When using a PKCS11 key such as the Yubikey, the current SSH agent implementation does not look for a certificate, and adding only a certificate without a private key file is not possible.

Note: the original ssh-agent is also lacking this feature.

Given that the agent protocol is reimplemented with yubikey-agent, it would be great to be able to add a certificate so that the agent is able to deliver both public keys and certificates.

The original Yubico doc and OpenSSH docs recommend using the CertificateFile option, but that's not an option when jumping from one ssh host to another (i.e. running ssh from a host we logged in with the certificate), because the way it works is by forwarding the agent socket, which in turn does not provides the certificate. The only currently existing solution with a hardware key is to distribute the ssh certificate on every host we plan to jump from, which is not feasible at scale.

See https://bugzilla.mindrot.org/show_bug.cgi?id=2472 for the never-fulfilled feature request on the OpenSSH agent.

with commit 742bc61
and pcsc-lite-devel-1.8.26-1.fc31.x86_64 on fedora 31

$ ykman info
Device type: YubiKey 4
Firmware version: 4.3.7
Enabled USB interfaces: FIDO+CCID

Applications
OTP Disabled
FIDO U2F Enabled
OpenPGP Enabled
PIV Enabled
OATH Enabled
FIDO2 Not available

$ ykman piv reset
WARNING! This will delete all stored PIV data and restore factory settings. Proceed? [y/N]: y
Resetting PIV data...
Success! All PIV data have been cleared from your YubiKey.
Your YubiKey now has the default PIN, PUK and Management Key:
PIN: 123456
PUK: 12345678
Management Key: 010203040506070801020304050607080102030405060708

I get the following error:

The default PIN did not work

printed out the err, which says:

smart card error 6a80: incorrect parameter in command data field

I have reset my old YubiKey 4 that I had lying around using both yubikey-agent -setup as well as ykman piv reset, and in both cases it prompts me for the PIN every single time, instead of once per session (which is what I expected to happen, based on the README). Is there a configuration option I'm missing?

This would allow yubikey-agent to be started socket-activated by systemd.
Background: https://vincent.bernat.ch/en/blog/2018-systemd-golang-socket-activation

We should have binary packages for Linux that install a user systemd unit.

0.1.3 was released in June, and there's been some development since then. I'm particularly interested in #46. Can a new release be cut please?

There seems to be something slightly strange going on for me on my mac:

if I run the agent directly myself (in the foreground) I can connect to the AUTH_SOCK and everything is fine.

On the other hand, if I attempt to let brew services start the agent (which I believe is root) my user can not longer access the agent AUTH_SOCK, I basically just get permission denied.

Do I have my mac set up in some strange way?

I am using PIV authentication for logging in to my computer and don't want to delete existing keys.

Setup should print the existing public key and then offer the flag to reset and start fresh. I can try to implement and create a PR if you accept this feature.

main.go currently shells out to osascript or notify-send when sending a notification:

https://github.com/FiloSottile/yubikey-agent/blob/master/main.go#L337-L339

It doesn't implement any notification logic for other platforms.

"https://github.com/gen2brain/beeep provides a cross-platform library for sending desktop notifications, alerts and beeps".

It doesn't rely on notify-send being in $PATH (only as a fallback, tries via dbus first), and in addition to Darwin, it also supports sending notifications on Windows.

I watched the Twitch stream after the fact. You were considering the auth sock name… The usual ssh agent uses its pid in the unix socket file name, which avoids conflicts in case of multiple instances.

If yubikey-agent is supposed to work with multiple instances of it running, it should probably do something similar, and PID is probably reasonable for this?

If it's not supposed to work with multiple instances running, it should probably fail startup with error. It does not do that currently.

I need a touch policy of cached in order to handle connecting to many servers at once during ansible provisioning. Adding a touch policy prompt during setup would be greatly appreciated.

First of all, thanks so much for creating this!

I own three identically configured YKs (4c, 5, neo), where the neo is the backup. All three keys have PIV enabled for macOS login, I just reuse slot 9a here.

Testing with Github, I've noticed that SSH auth with the Neo does not seem to work.

YK 4C (works as expected):

> ssh -T [email protected]
Hi felixhammerl! You've successfully authenticated, but GitHub does not provide shell access.

YK 5 (works as expected):

> ssh -T [email protected]
Hi felixhammerl! You've successfully authenticated, but GitHub does not provide shell access.

YK Neo:

> ssh -T [email protected]
sign_and_send_pubkey: signing failed: agent refused operation
[email protected]: Permission denied (publickey).
> killall -HUP yubikey-agent
> ssh -T [email protected]
sign_and_send_pubkey: signing failed: agent refused operation
[email protected]: Permission denied (publickey).

PGP is not in use on the YKs. Not sure what the issue might be.

> cat ~/.ssh/config
Host *
    IdentityAgent /usr/local/var/run/yubikey-agent.sock

The current suggestion of setting SSH_AUTH_SOCK to /usr/local/var/run/yubikey-agent.sock doesn't take shared, multi-user systems into account, i.e. switch user, etc.

Setting it to /tmp/${USER}-yubikey-agent.socket or $HOME/.yubikey-agent.sock, etc. would probably make more sense, no?

Situation

I picked up #29 rebased it on master, took care of the comments in the MR and fixed some minor issues. See #69
I kept small commits for now, so it's easier to follow my changes.

I reached a state where the agent works but got stuck with a problem that blocks me from using it for me.

Problem

Windows has a timeout for smartcard transactions (default: 5 seconds)

If a transaction is held on the card for more than five seconds with no operations happening on that card, then the card is reset.
Source: https://docs.microsoft.com/en-us/windows/win32/api/winscard/nf-winscard-scardbegintransaction?redirectedfrom=MSDN

This does not play well with yubikey-agent:

1. If you were asked to enter the new PIN during setup. You need to be quick. If you need more than 5 seconds to enter the PIN twice, you will fail. This I fixed with 4f046ef
2. You have only 5 seconds to enter the PIN for normal agent usage, too
3. If you entered the pin, you can start as many ssh sessions as you want within 5 seconds and than you have to enter the PIN again.
   There is a registry setting to increase the timeout, but I'm not sure about the side effects and this would only help to mitigate the problem but not solve it.

Idea

Actually I don't like that the card connections are open forever. I can imagine that this might cause other problems, too. I had for example weird things happening when I had the YubiKey Manager open and worked on yubikey-agent. But I was not aware of the timeout at that time, so that might have caused most of the weirdness.

My idea to approach this problem:

1. Cache the pin in yubikey-agent and define an own timeout.
2. Open a new connection (transaction?) to the YubiKey for every request.

Unfortunately I struggle to find a starting point here.

• Is yubikey-agent even the right place to deal with that or should this go to one of the libraries used? Which one?
• Can this cause side effects on other operating systems? I don't think so, but ...
• Would this have a bigger impact on the general structure of yubikey-agent?
• Is it weakening the security if the PIN is cached?

I would be able to spend some time on this but I will need someone to confirm that this is wanted to be implemented and support. At least for general design questions and testing.

Reproduction

Reset and configure key policy

$ ykman piv reset
WARNING! This will delete all stored PIV data and restore factory settings. Proceed? [y/N]: y
Resetting PIV data...
Success! All PIV data have been cleared from your YubiKey.
Your YubiKey now has the default PIN, PUK and Management Key:
	PIN:	123456
	PUK:	12345678
	Management Key:	010203040506070801020304050607080102030405060708
$ ykman piv import-key --pin-policy ALWAYS --touch-policy ALWAYS 9a key.pem
Enter a management key [blank to use default key]: 
$ ykman piv generate-certificate -s $USER 9a public.pem              
Enter PIN: 
Enter a management key [blank to use default key]: 
Touch your YubiKey...

Start agent and set up authorized_keys

$ yubikey-agent &
$ export SSH_AUTH_SOCK="/Users/joneskoo/Library/Caches/yubikey-agent.sock"
$ ssh-add -L  | set-up-authorized-keys server

First login works

PIN is prompted and touch is required as expected.

$ ssh server
Login OK.

Second login

Touch is required but PIN is not prompted.

$ ssh server
sign_and_send_pubkey: signing failed: agent refused operation

Agent refuses and yubikey-agent logs:

2020/04/27 00:18:35 agent 13: command failed: smart card error 6982: security status not satisfied

We're using yubikeys (4.3) which contain preloaded keys to reach specific requirement for keys which are not possible with them being generated on the yubikey itself. Hence no attestion certs on the yubikey for imported keys.

yubikey-agent errors (on key usage via ssh) with:

2021/01/02 11:57:33 Connecting to the YubiKey...
2021/01/02 11:59:38 agent 13: failed to prepare private key: get attestation cert: data object or application not found

How is it possible to work around it and use such yubikeys? (Just to be clear, they're NOT provisioned using --setup option)

Is it possible to add other types of SSH keys to the agent as well? Currently, I can't add RSA or ed25519 keys.

/Users/andreicek/maandagapp% ssh-add ~/.ssh/id_rsa
Enter passphrase for /Users/andreicek/.ssh/id_rsa:
Could not add identity "/Users/andreicek/.ssh/id_rsa": agent refused operation
/Users/andreicek/maandagapp% ssh-add ~/.ssh/id_ed25519
Enter passphrase for /Users/andreicek/.ssh/id_ed25519:
Could not add identity "/Users/andreicek/.ssh/id_ed25519": agent refused operation

In README's "Alternatives" section, regarding to the use of ssh-agent, the paragraph about macOS assumes the need for a third-party PKCS#11 library and reasonably talks about its UX issues regarding library load path allow list.

The ssh-agent that ships with macOS (which is pretty cool, as it starts on demand and is preconfigured in the environment) also has restrictions on where the .so modules can be loaded from. It can see through symlinks, so a Homebrew-installed /usr/local/lib/libykcs11.dylib won't work, while a hard copy at /usr/local/lib/libykcs11.copy.dylib will.

On the other hand, macOS already ships with a PKCS#11 support library at /usr/lib/ssh-keychain.dylib that can be used by OpenSSH. As of macOS Catalina it only supports RSA keys but otherwise is functional.

% nm -j /usr/lib/ssh-keychain.dylib | egrep '^_C_\w+'
_C_CloseSession
_C_Finalize
_C_FindObjects
_C_FindObjectsFinal
_C_FindObjectsInit
_C_GetAttributeValue
_C_GetFunctionList
_C_GetInfo
_C_GetSlotList
_C_GetTokenInfo
_C_Initialize
_C_Login
_C_OpenSession
_C_Sign
_C_SignInit

Do you think this paragraph is still pertinent? I can put a PR mentioning /usr/lib/ssh-keychain.dylib and just remove this paragraph to keep things simple.

https://github.com/FiloSottile/yubikey-agent/blob/master/setup.go#L69

When --setup is rerun, the tool should print out the public key, as a convenience.

I am having an issue with a Yubikey 5ci on macOS 10.15.5. The output in the yubikey-agent.log says:

❯ cat /usr/local/var/log/yubikey-agent.log
Connecting to the YubiKey...
agent 13: failed to prepare private key: parse attestation cert: parsing extension: unrecognized formfactor: 0x5

This seems to have been resolved in a commit upstream in piv-go (see link below). I don't think its included in latest release that has been cut for that repo though. Can a new version be cut and pulled in and a new release of yubikey-agent cut?

go-piv/piv-go#62

The issue in #32 has the same output and it might be a related issue, but the submitter of that issue didn't include the log output so I can't be sure its the same.

I don't have my yubikey in direct eye view, would be convenient if the desktop notification showed immediately or on a configurable delay

I have version 0.1.1 installed with Homebrew. I noticed that yubikey-agent stopped working. From /usr/local/var/log/yubikey-agent.log:

Failed to listen on UNIX socket: listen unix /usr/local/var/run/yubikey-agent.sock: bind: no such file or directory

(Side note: lack of timestamps in the log is mildly annoying.)

Seemingly the run directory disappeared from /usr/local/var/, and the only thing I can think of is today's macOS update to 10.15.5, which might have nuked it (or perhaps the reboot?). Recreating the directory brought the service back to life.

Should yubikey-agent ensure this directory exists (instead of the Homebrew script)?

Hello @FiloSottile I'm curious if you're already interested in a windows port. In your last stream you stated that you would like to have windows on board but later on. If you're already in the state of accepting PRs which add functionalities I would be happy to work with you in order to contribute my work back.

If you want to have a look, the code is over at tobiaskohlbau/yubikey-agent. For now it depends on a local version of go-piv/piv-go but this should be obsolete as soon as go-piv/piv-go#57 is merged.

This works out of the box with the ssh client which is included in windows 10. With the help of another utility program it's also possible to get the ssh-agent into WSL2(windows subystem for linux).

BTW thanks for your work and your stream :-). This taught me that their exist other ways than gpg to use my yubikey for ssh.

thanks a lot for this great project. I just got new yubikeys and moved my new SSH keys to them using Yubikey-agent! While doing this I stumbled across a subtle issue though:

Right now setup.go uses terminal.ReadPassword while main.go uses github.com/gopasspw/gopass/pkg/pinentry.

The gopass pinentry communication code unfortunately has a subtle bug that replaces all % signs with %25 (see gopasspw/gopass#1621).

Due to this bug and the different implementations it's possible to create a PIN with a % sign during setup which will then be incorrectly read as %25 from pinentry when the agent is running in the background. This will then result in strange "agent refused operation" errors when using ssh.

The unescaping should probably be fixed in gopass/pkg/pinentry but I believe both setup.go and main.go should use the same method to request the PIN for consistency. If they had used the same method the failure would've already occurred during setup (because my PIN would've been > 8 chars) and it would've been a little bit easier to track this down.

If you agree I can create a PR to unify the get pin logic in main.go and setup.go on the weekend.

Would it make sense to have this project compatible with smimesign from GitHub? Or to implement similar functionality for git commit signing.

The systemd unit at /contrib/systemd/user/yubikey-agent.service implies that it is suitable for the user systemd daemon, however it contains options that required privileges to run, resulting in errors similar to the following:

systemd[28428]: yubikey-agent.service: Failed to set up mount namespacing: Operation not supported
systemd[28428]: yubikey-agent.service: Failed at step NAMESPACE spawning /usr/bin/yubikey-agent: Operation not supported

This is reflected in similar issues upsteam, such as systemd/systemd#9870. I can try paring the list down to options that work.

yubikey-agent should not be run as root, but Homebrew autocatically shows sudo brew services start, causing issues like #16.

Running on Ubuntu 20.04, when trying to login, I get:

agent 11: could not get public key: command failed: smart card error 6a82: data object or application not found

I have private keys loaded on my Yubikey 5 that I created via gpg. I have SSH_AUTH_SOCK set and I installed libpcsclite-dev per piv-go instructions. I also killed gpg-agent. Any ideas what might be going on? I

v0.1.2 seems to have been tagged, but the homebrew formula was not updated to reflect that.

https://github.com/FiloSottile/yubikey-agent/commits/v0.1.2

Hey, thanks a lot for creating this project!

One question comes to my mind: is it possible to import existing SSH keys to a Yubikey (using any mechanism, not necessarily yubikey-agent itself) so that yubikey-agent can use them just like the keys it created on the device? Assuming it's not possible right now and it's just something that's not implemented in yubikey-agent – is it likely to exist in the future? Are pull requests implementing it welcome?

My use case is to generate a key on a trusted secure machine (temporary, disposable and clean system, no network etc.), upload it to a Yubikey and also store an encrypted copy on a usb-stick for extra safety in case my Yubikey stops working at some point. (Having multiple Yubikeys with different SSH keys on each of them is not suitable for me.)

Hi I installed this package using the AUR package and ran the following:

systemctl daemon-reload --user
sudo systemctl enable --now pcscd.socket
systemctl --user enable --now yubikey-agent

But then I realize, when the computer is rebooted, the yubikey-agent do not restart, this cause the SSH_AUTH_SOCK to not be found.

Here is the output for systemctl --user status yubikey-agent

● yubikey-agent.service - Seamless ssh-agent for YubiKeys
     Loaded: loaded (/usr/lib/systemd/user/yubikey-agent.service; enabled; vend>
     Active: inactive (dead)
       Docs: https://filippo.io/yubikey-agent

System information:

OS: Manjaro 20.0.3 Lysia
Kernel: x86_64 Linux 5.6.16-1-MANJARO
DE: GNOME 3.36.3

Anyhelp would be nice, thank you

I had everything working fine and then i woke up after an update of some SW on Manjaro and i can no longer find the yubikey-agent.sock

How do i know where to find this file on arch/manjaro?

i had this in my zshell .zshrc, it used to work yesterday

export SSH_AUTH_SOCK="/var/run/user/1000/yubikey-agent/yubikey-agent.sock"

and then today i can no longer find this flie after some system updates.

How do i get this file and where do i place it?

i uninstalled and reinstalled yubikey-agent and i still cant find this file.

I am on Manjaro Linux Kernel 5.10.13-2, yubikey agent is failing to load..

Thanks for building this. With the systemd config as given I hit errors like the following

Jul 03 20:34:44 ubuntu systemd[30813]: yubikey-agent.service: Failed to set up user namespacing: Operation not permitted
Jul 03 20:34:44 ubuntu systemd[30813]: yubikey-agent.service: Failed at step USER spawning /usr/local/bin/yubikey-agent: Operation not permitted

and I ended up removing lots of flags in the service section:

[Service]
ExecStart=/usr/local/bin/yubikey-agent -l %t/yubikey-agent/yubikey-agent.sock
ExecReload=/bin/kill -HUP $MAINPID
RuntimeDirectory=yubikey-agent

I know it is a great idea to use as little privilege as possible. OTOH, since kernels shipped by Ubuntu might not work well with such settings yet, it would be nice if we could provide a little more information to the users.

Reference: https://unix.stackexchange.com/questions/303213/how-to-enable-user-namespaces-in-the-kernel-for-unprivileged-unshare

BTW, sysctl settings like

sudo sysctl -w kernel.unprivileged_userns_clone=1
sudo sysctl -w kernel.unprivileged_userns_apparmor_policy=1

does not make it work for me 😞

Hi!

Thanks for all the efforts you put into this project!
But does this project still supported/maintained?

Are there any future plans or roadmap?

I see Issues just not get any attention and PRs are ignored/closed.

Now the setup only prompts for PIN.

It should explicitly say if management PIN and PUK have been set up. It says it is locked if wrong PIN is entered 3 times. But what after it's locked, do you need to reset or is there something else?

If there's some "advanced usage", maybe point to doc how to do it? At minimum should say if PUK/management secret were randomized or not, and if they're available somehow.

Would it be a problem to print them and say "store securely in password manager"? In either case it should be explicitly said if it is randomized or default.

ciao Filippo,

according to the signals.Notify documentation, the channel should be buffered:

Package signal will not block sending to c: the caller must ensure that c has sufficient
buffer space to keep up with the expected signal rate. For a channel used for notification
of just one signal value, a buffer of size 1 is sufficient.

I have to admit that I have always been partially confused by this requirement and by the various discussions that pop up from googling the subject.

Maybe in this particular case there is no practical difference but I noticed it:

It should be possible to support two different keys with different touch policy on Yubikey. This would allow having some more sensitive services require a touch, but also enable other services to still use the hardware key but no touch required, only PIN per session.

Primary use case for me now is Github; I have auto-fetch on my editor and it keeps prompting for touch. It is making way too many (unidentified, #8 ) prompts for touch. If I could use a second slot on the same key for no-touch use cases, it would not be a problem, as long as SSH doesn't trigger signing and therefore touch for the passive other key with touch-required.

Currently the tool supports PINs of up to 8 characters, due to limitations from the YubiKeys. However, this limits the possibility of using passphrases, which are easier to remember. The YubiKey does a good job to prevent bruteforcing, but I think it's still worth adding this functionality.

The idea is to have a PIN, and then use its Base-n hash format, or at least the first 8 encoded characters of it.

This can allow for an unlimited (or at least larger) PIN to be set, and with the proper CLI tool, or maybe even website, someone can determine the YubiKey PIN based on the entered PIN, using the same algorithm.

I am getting errors trying to make this work with my YubiKey :

• macOS Catalina 10.15.4
• YubiKey 4.2.8
• yubikey-agent: stable 0.1.1

yubikey-agent.log

Connecting to the YubiKey...
Reconnecting to the YubiKey...
agent 13: failed to prepare private key: get attestation cert: command failed: smart card error 6d00
agent 17: operation unsupported

SSH log

ssh -v -T [email protected]
OpenSSH_8.1p1, LibreSSL 2.7.3
debug1: Reading configuration data /Users/philippe/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 47: Applying options for *
debug1: Connecting to github.com port 22.
debug1: Connection established.
debug1: identity file /Users/philippe/.ssh/id_rsa type -1
debug1: identity file /Users/philippe/.ssh/id_rsa-cert type -1
debug1: identity file /Users/philippe/.ssh/id_dsa type -1
debug1: identity file /Users/philippe/.ssh/id_dsa-cert type -1
debug1: identity file /Users/philippe/.ssh/id_ecdsa type -1
debug1: identity file /Users/philippe/.ssh/id_ecdsa-cert type -1
debug1: identity file /Users/philippe/.ssh/id_ed25519 type -1
debug1: identity file /Users/philippe/.ssh/id_ed25519-cert type -1
debug1: identity file /Users/philippe/.ssh/id_xmss type -1
debug1: identity file /Users/philippe/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.1
debug1: Remote protocol version 2.0, remote software version babeld-a950f115
debug1: no match: babeld-a950f115
debug1: Authenticating to github.com:22 as 'git'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: rsa-sha2-512
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ssh-rsa SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8
debug1: Host 'github.com' is known and matches the RSA host key.
debug1: Found key in /Users/philippe/.ssh/known_hosts:1
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: YubiKey #4250300 PIV Slot 9a ECDSA SHA256:d4oDsV8IJotbZPVnmCgWbKTkwv4cwVlf81CFaMWkU6w agent
debug1: Will attempt key: /Users/philippe/.ssh/id_rsa
debug1: Will attempt key: /Users/philippe/.ssh/id_dsa
debug1: Will attempt key: /Users/philippe/.ssh/id_ecdsa
debug1: Will attempt key: /Users/philippe/.ssh/id_ed25519
debug1: Will attempt key: /Users/philippe/.ssh/id_xmss
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,rsa-sha2-512,rsa-sha2-256,ssh-dss>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: YubiKey #4250300 PIV Slot 9a ECDSA SHA256:d4oDsV8IJotbZPVnmCgWbKTkwv4cwVlf81CFaMWkU6w agent
debug1: Server accepts key: YubiKey #4250300 PIV Slot 9a ECDSA SHA256:d4oDsV8IJotbZPVnmCgWbKTkwv4cwVlf81CFaMWkU6w agent
sign_and_send_pubkey: signing failed: agent refused operation
debug1: Trying private key: /Users/philippe/.ssh/id_rsa
debug1: Trying private key: /Users/philippe/.ssh/id_dsa
debug1: Trying private key: /Users/philippe/.ssh/id_ecdsa
debug1: Trying private key: /Users/philippe/.ssh/id_ed25519
debug1: Trying private key: /Users/philippe/.ssh/id_xmss
debug1: No more authentication methods to try.
[email protected]: Permission denied (publickey).

In the README you have the following snippet to show how to use yubikey-agent for all hosts but one:

Host *
    IdentityAgent /usr/local/var/run/yubikey-agent.sock

Host example.com
    IdentityAgent $SSH_AUTH_SOCK

SSH will apply the first match so the order here needs to be reversed. As written example.com will attempt to use yubikey-agent.

README states:

yubikey-agent -setup generates a random Management Key and stores it in PIN-protected metadata. Note that this is a different scheme from the ykman one, which enables PIN bruteforcing.

I think this is referring to an older scheme used by the YubiKey PIV Manager.

ykman can actually store the management key in a pin protected part of the device, using the --protect flag. I have not verified it yet, but it looks like yubikey-agent and ykman should be compatible in this regard.

On Linux, running yubikey-agent -install should create, install, and start a local user systemd unit, and show the environment variable the user needs to set (where the socket is in a relevant stable path in the home).

SSH connection hanging due to touch required can be confusing at least in the beginning / after long time. It would be good to indicate to the user somehow that touch is required. Blinking light can be easy to miss, depending on physical placement of the key.

At least on macOS, if I have yubikey-agent running and I have authenticated with it (just starting yubikey-agent does not reproduce the problem), Yubikey Manager hangs. It appears to hang in a call to PCSC, and with some experiments the PIV application seems to be where it blocks - which makes sense obviously.

I'm creating this to make a reminder now to document this behavior in upcoming README (including how to stop the agent if Yubikey Manager is needed). Depending on how setup will work, maybe the Yubikey Manager is not needed by general audience but there needs to be a way to free the interface (easiest to stop the agent). Feel free to close/replace with some other TODO of course.

I am using my Yubikey for both GPG and yubikey-agent and trying to find a descent workaround for the go-piv/piv-go#47 issue. I am fine to loose the PIN caching (I can use libsecret to store the pin for me on the machine I trust) and killall -HUP yubikey-agent workaround kind of works, except this command needs to be issued manually. Can we add functionality to release the smart card context on timeout after last key access? This would allow to me configure context auto-release and make yubikey-agent and gpg-agent co-existence a bit easier.

$ go run . -setup --really-delete-all-piv-keys
Resetting YubiKey PIV applet...
Failed to reset YubiKey: blocking pin: verify pin: smart card error 6302
exit status 1

Strangely, it does succeed if you repeat the command a couple of times. This happens with a Yubikey Neo on Arch Linux.

Using latest version from git on Arch with Yubikey 5 Nano and trying to cache the PIN to the system keystore. Saving the pin to the store works and I see it there, however agent fails to read/use the value from the store.

When trying to ssh to the host (after service restart, so pin entry is required), I am getting the following error message:

sign_and_send_pubkey: signing failed for ECDSA "YubiKey #XXXXXXXX PIV Slot 9a" from agent: agent refused operation

In the service log I see the following:

Jan 09 17:45:38 pan-cf-sv9 yubikey-agent[4814]: 2021/01/09 17:45:38 agent 13: pin prompt: unexpected response: S PASSWORD_FROM_CACHE

Does it suppose to work? Am I doing something wrong here?

I'm currently using the OpenPGP applet on my Yubikey for two things: SSH authentication and password decryption with pass. Given all the well-known UX issues with gpg and smart cards/hardware tokens, I would like to switch to yubikey-agent, (r)age & PIV. Most of the ecosystem is there or not hard to build (such as a pass clone that relies on age), but currently the two use cases authentication and decryption don't work well simultaneously due to the need for exclusive reader access.

A convenient feature of gpg that works around the "reader lock" issue is that it can work as an agent for both SSH auth and decryption. What are thoughts about adding decryption agent functionality to yubikey-agent, which could then be used by (r)age?