Interestingly, my YubiKey 5 seems to persist the PIN cache across sessions, and even yubikey-agent restarts (but not unplug-replug cycles, as expected). In this case it would be far more acceptable to just drop the session every time.

I bet using a different applet will still trash the PIN cache, but that's probably ok.

Actually, I looked again at #57 and I like the approach of having a separate command better, so let's call this yubikey-agent-keygen, with the same semantics.

Not saying that we necessarily shouldn’t do this, but it’s worth noting that if you have a URL, getting the original behavior back is a single call to strings.Replace(u, “;”, “&”, -1).

This adds an optional setup flag that allows the touch policy to be set. ~to "cache for 15 seconds" instead of "always".~

~I've tried to add this feature in the least obtrusive way possible, but the command line is getting a little complex for the plain old flag package. Would there be any interest in using a CLI library in yubikey-agent?~

Closes: #52

Thank you for the PR. I don't want to add options to -setup, but I came around to adding a configurable -new-key for additional keys with more flexibility. See #95.

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?

It looks like this is indeed the linked upstream issue. If you could pop in there and report your firmware version and whether it supports PIN caching, that would be great.

This should be resolved by #95, please check out the plan there.

This will be resolved by #95

The -new-key command generates a new key in one of the numbered "retired" slots with a certificate with CN="SSH key".

The -touch-policy, -pin-policy, and -key-type flags control the respective aspects of this additional key.

There is no way to delete a key with yubikey-agent, instead the README will explain how to use YubiKey Manager for that.

yubikey-agent will support all ECDSA, Ed25519, and RSA keys in the Authorization and retired slots of all connected PIV tokens, as long as they were generated on device and the Common Name of the certificate is SSH key. (This allows ignoring age keys, which otherwise would leak to remote SSH servers.)

(This will break some current keys generated by other tools, but those were never and won't be officially supported.)

Thank you!

Fix wording in function comment.

Environment

HOMEBREW_VERSION: 3.2.2
ORIGIN: https://github.com/Homebrew/brew
HEAD: 7d37d09709b6fbd5b89b468eb0b4438ffa0fb81c
Last commit: 3 days ago
Core tap ORIGIN: https://github.com/Homebrew/homebrew-core
Core tap HEAD: aa4b76139630680884c2823727d7ffa773289fb0
Core tap last commit: 5 minutes ago
Core tap branch: master
HOMEBREW_PREFIX: /usr/local
HOMEBREW_CASK_OPTS: []
HOMEBREW_MAKE_JOBS: 12
Homebrew Ruby: 2.6.3 => /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/bin/ruby
CPU: dodeca-core 64-bit kabylake
Clang: 12.0.5 build 1205
Git: 2.30.1 => /Applications/Xcode.app/Contents/Developer/usr/bin/git
Curl: 7.64.1 => /usr/bin/curl
macOS: 11.4-x86_64
CLT: 12.5.1.0.1.1623191612
Xcode: 12.5.1

I was trying to install age on my macbook pro, but installation failed and got following error message:

brew install age
==> Downloading https://github.com/FiloSottile/age/archive/v1.0.0-rc.3.zip
Already downloaded: /Users/jiangs/Library/Caches/Homebrew/downloads/3da94ea27efb60f1321ee161792e28cb0f4cc8e6e2ce27fc5739b8d26e8e1029--age-1.0.0-rc.3.zip
==> go build -o /usr/local/Cellar/age/1.0.0-rc.3/bin -ldflags -X main.Version=v1.0.0-rc.3 filippo.io/age/cmd/...
Last 15 lines from /Users/jiangs/Library/Logs/Homebrew/age/01.go:
/usr/local/Cellar/age/1.0.0-rc.3/bin
-ldflags
-X main.Version=v1.0.0-rc.3
filippo.io/age/cmd/...
runtime/cgo
In file included from gcc_libinit.c:8:
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/pthread.h:229:66: error: unknown type name 'size_t'
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/pthread.h:246:43: error: unknown type name 'size_t'
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/pthread.h:253:66: error: unknown type name 'size_t'
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/pthread.h:521:1: error: unknown type name 'size_t'
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/pthread.h:584:23: error: unknown type name 'size_t'
gcc_libinit.c:97:18: error: variable has incomplete type 'struct timespec'
gcc_libinit.c:97:9: note: forward declaration of 'struct timespec'
gcc_libinit.c:110:3: error: implicit declaration of function 'nanosleep' is invalid in C99 [-Werror,-Wimplicit-function-declaration]

Do not report this issue to Homebrew/brew or Homebrew/core!

Traceback (most recent call last):
	26: from /usr/local/Homebrew/Library/Homebrew/build.rb:229:in `<main>'
	25: from /usr/local/Homebrew/Library/Homebrew/build.rb:133:in `install'
	24: from /usr/local/Homebrew/Library/Homebrew/utils.rb:550:in `with_env'
	23: from /usr/local/Homebrew/Library/Homebrew/build.rb:138:in `block in install'
	22: from /usr/local/Homebrew/Library/Homebrew/formula.rb:1260:in `brew'
	21: from /usr/local/Homebrew/Library/Homebrew/formula.rb:2375:in `stage'
	20: from /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/forwardable.rb:230:in `stage'
	19: from /usr/local/Homebrew/Library/Homebrew/resource.rb:91:in `stage'
	18: from /usr/local/Homebrew/Library/Homebrew/resource.rb:116:in `unpack'
	17: from /usr/local/Homebrew/Library/Homebrew/resource.rb:199:in `mktemp'
	16: from /usr/local/Homebrew/Library/Homebrew/mktemp.rb:63:in `run'
	15: from /usr/local/Homebrew/Library/Homebrew/mktemp.rb:63:in `chdir'
	14: from /usr/local/Homebrew/Library/Homebrew/mktemp.rb:63:in `block in run'
	13: from /usr/local/Homebrew/Library/Homebrew/resource.rb:117:in `block in unpack'
	12: from /usr/local/Homebrew/Library/Homebrew/download_strategy.rb:102:in `stage'
	11: from /usr/local/Homebrew/Library/Homebrew/download_strategy.rb:115:in `chdir'
	10: from /usr/local/Homebrew/Library/Homebrew/download_strategy.rb:115:in `chdir'
	 9: from /usr/local/Homebrew/Library/Homebrew/resource.rb:121:in `block (2 levels) in unpack'
	 8: from /usr/local/Homebrew/Library/Homebrew/formula.rb:2395:in `block in stage'
	 7: from /usr/local/Homebrew/Library/Homebrew/utils.rb:550:in `with_env'
	 6: from /usr/local/Homebrew/Library/Homebrew/formula.rb:2396:in `block (2 levels) in stage'
	 5: from /usr/local/Homebrew/Library/Homebrew/formula.rb:1267:in `block in brew'
	 4: from /usr/local/Homebrew/Library/Homebrew/build.rb:178:in `block (2 levels) in install'
	 3: from /usr/local/Homebrew/Library/Taps/filippo.io/homebrew-age/HomebrewFormula/age.rb:18:in `install'
	 2: from /usr/local/Homebrew/Library/Homebrew/formula.rb:2166:in `system'
	 1: from /usr/local/Homebrew/Library/Homebrew/formula.rb:2166:in `open'
/usr/local/Homebrew/Library/Homebrew/formula.rb:2230:in `block in system': Failed executing: go build -trimpath -o /usr/local/Cellar/age/1.0.0-rc.3/bin -ldflags -X\ main.Version=v1.0.0-rc.3 filippo.io/age/cmd/... (BuildError)
	5: from /usr/local/Homebrew/Library/Homebrew/brew.rb:155:in `<main>'
	4: from /usr/local/Homebrew/Library/Homebrew/brew.rb:167:in `rescue in <main>'
	3: from /usr/local/Homebrew/Library/Homebrew/exceptions.rb:509:in `dump'
	2: from /usr/local/Homebrew/Library/Homebrew/exceptions.rb:455:in `issues'
	1: from /usr/local/Homebrew/Library/Homebrew/exceptions.rb:459:in `fetch_issues'
/usr/local/Homebrew/Library/Homebrew/utils/github.rb:60:in `issues_for_formula': undefined method `full_name' for nil:NilClass (NoMethodError)

It looks like your Command Line Tools installation is broken, it doesn't look like it's an age-specific issue.

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

I would take a PR for this, but can't implement it myself as I don't regularly use Linux desktop environments.

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.

github.com/gen2brain/beeep is a very large dependency tree for a tangential feature such as the notifications. I think we'll take the tradeoff here.

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 https://github.com/gopasspw/gopass/issues/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.

A (r)age plugin that uses yubikey-agent is on the roadmap :)

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.)

I understand the use case, but it's an advanced scenario that we will not support in -setup. We might allow using such a key once it's been generated with some other tool. See #91 for that.

Thank you for the PR, but I don't want to support importing keys in -setup. yubikey-agent is a simple opinionated tool that makes these choices for the user.

I might consider fixes that make it possible to import keys with other tools and then use them with yubikey-agent, if they are small enough, but see #91.

This is to allow creating backups of the private key in case the YubiKey gets lost or damaged. The word "insecurely" is appended to the name of the switch and a long warning produced in order to make people who don't know what they're doing turn away and stop what they're doing.

This is possible since piv-go 1.7.0[1] so I allowed myself to bump the version of this requirement.

While I do have several doubts about approaching this (see below) I believe this is a useful thing to have. What I'm unsure about is:

• The code quality (I'm not writing Go day to day)
• I may have done something stupid cryptography-wise here, I'm not a cryptographer or a security specialist
• How to warn properly so that people not knowing what they're doing don't use the new switch – I think I've done a decent job here
• Should this be mentioned in the readme? I mentioned it for documentation purposes
• Should this be mentioned in the --help output? The existing --really-delete-all-piv-keys flag is not there so I skipped it
• Should there be advice that when this option is used it's better to do it on a clean system, on a trusted machine, offline and airgapped ideally, and any potential backups should be encrypted and stored securely?
• Should the main agent daemon always handle keys that fail attestation (caused by generating on the computer instead of on the device) like I added here or maybe make this configurable with a switch?

Closes GH-65.

[1] https://github.com/go-piv/piv-go/pull/83#issuecomment-740707527

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