GithubHelp home page GithubHelp logo

maximbaz / yubikey-touch-detector Goto Github PK

View Code? Open in Web Editor NEW
383.0 8.0 30.0 231 KB

A tool to detect when your YubiKey is waiting for a touch (to send notification or display a visual indicator on the screen)

License: ISC License

Go 92.28% Makefile 7.72%
yubikey golang u2f openpgp touch webauthn go gpg ssh notifier

yubikey-touch-detector's Introduction

YubiKey touch detector

This is a tool that can detect when YubiKey is waiting for your touch. It is designed to be integrated with other UI components to display a visible indicator.

For example, an integration with i3wm and py3status looks like this:

demo

See also: Wiki: Which UI components are already integrated with this app?

Installation

This tool only works on Linux. If you want to help implementing (at least partial) support for other OS, pull requests are very welcome!

On Arch Linux, you can install it with pacman -S yubikey-touch-detector

The package also installs a systemd service and socket. If you want the app to launch on startup, just enable the service like so:

$ systemctl --user daemon-reload
$ systemctl --user enable --now yubikey-touch-detector.service

If you want the service to be started only when there is a listener on Unix socket, enable the socket instead like so:

$ systemctl --user daemon-reload
$ systemctl --user enable --now yubikey-touch-detector.socket

Alternatively you can download the latest release from the GitHub releases page. All releases are signed with my PGP key.

Finally you can install the app with go:

  • For Go <1.17
$ go get -u github.com/maximbaz/yubikey-touch-detector
$ go install github.com/maximbaz/yubikey-touch-detector@latest

This places the binary in your $GOPATH/bin folder, as well as the sources in $GOPATH/src for you to use the detection functions in your own code.

Usage

Command line

To test how the app works, run it in verbose mode to print every event on STDERR:

$ yubikey-touch-detector -v

Now try different commands that require a physical touch and see if the app can successfully detect them.

Desktop notifications

You can make the app show desktop notifications using libnotify if you run it with corresponding flag:

$ yubikey-touch-detector --libnotify

Configuring the app

The app supports the following environment variables and CLI arguments (CLI args take precedence):

Environment var CLI arg
YUBIKEY_TOUCH_DETECTOR_VERBOSE -v
YUBIKEY_TOUCH_DETECTOR_LIBNOTIFY --libnotify
YUBIKEY_TOUCH_DETECTOR_STDOUT --stdout
YUBIKEY_TOUCH_DETECTOR_NOSOCKET --no-socket

You can configure the systemd service by defining any of these environment variables in $XDG_CONFIG_HOME/yubikey-touch-detector/service.conf - see service.conf.example for a configuration example.

Integrating with other UI components

First of all, make sure the app is always running (e.g. start a provided systemd user service or socket).

Next, in order to integrate the app with other UI components to display a visible indicator, use any of the available notifiers in the notifier subpackage.

notifier/unix_socket

unix_socket notifier allows anyone to connect to the socket $XDG_RUNTIME_DIR/yubikey-touch-detector.socket and receive the following events:

event description
GPG_1 when a gpg operation started waiting for a touch
GPG_0 when a gpg operation stopped waiting for a touch
U2F_1 when a u2f operation started waiting for a touch
U2F_0 when a u2f operation stopped waiting for a touch

All messages have a fixed length of 5 bytes to simplify the code on the receiving side.

How it works

Your YubiKey may require a physical touch to confirm these operations:

  • sudo request (via pam-u2f)
  • WebAuthn
  • gpg --sign
  • gpg --decrypt
  • ssh to a remote host (and related operations, such as scp, rsync, etc.)
  • ssh on a remote host to a different remote host (via forwarded ssh-agent)

See also: FAQ: How do I configure my YubiKey to require a physical touch?

Detecting u2f operations

In order to detect whether a U2F/FIDO2 operation requests a touch on YubiKey, the app is listening on the appropriate /dev/hidraw* device for corresponding messages as per FIDO spec.

See detector/u2f.go for more info on implementation details, the source code is documented and contains relevant links to the spec.

Detecting gpg operations

This detection is based on a "busy check" - when the card is busy (i.e. gpg --card-status hangs), it is assumed that it is waiting on a touch. This of course leads to false positives, when the card is busy for other reasons, but it is a good guess anyway.

In order to not run the gpg --card-status indefinitely (which leads to YubiKey be constantly blinking), the check is being performed only after $GNUPGHOME/pubring.kbx (or $HOME/.gnupg/pubring.kbx) file is opened (the app is thus watching for OPEN events on that file).

If the path to your pubring.kbx file differs, define $GNUPGHOME environment variable, globally or in $XDG_CONFIG_HOME/yubikey-touch-detector/service.conf.

Since v1.11.0 we started using gpgme to perform some operations above:

  • we are now using Assuan protocol to query card status, instead of spawning gpg --card-status processes.
  • we are now querying path to pubring.kbx from gpgme.

Detecting ssh operations

The requests performed on a local host will be captured by the gpg detector. However, in order to detect the use of forwarded ssh-agent on a remote host, an additional detector was introduced.

This detector runs as a proxy on the $SSH_AUTH_SOCK, it listens to all communications with that socket and starts a gpg --card-status check in case an event was captured.

FAQ

How do I configure my YubiKey to require a physical touch?

For sudo requests with pam-u2f, please refer to the documentation on Yubico/pam-u2f and online guides (e.g. official one).

For gpg and ssh operations, install ykman and use the following commands:

$ ykman openpgp set-touch sig on   # For sign operations
$ ykman openpgp set-touch enc on   # For decrypt operations
$ ykman openpgp set-touch aut on   # For ssh operations

If you are going to frequently use OpenPGP operations, cached or cached-fixed may be better for you. See more details here.

Make sure to unplug and plug back in your YubiKey after changing any of the options above.

yubikey-touch-detector's People

Contributors

cyrinux avatar daisukixci avatar e1mo avatar fallenwarrior2k avatar impl avatar invidian avatar jollheef avatar lentinj avatar maximbaz avatar mlofjard avatar mochaap avatar n-st avatar neiro21 avatar pfoo avatar skbolton avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

yubikey-touch-detector's Issues

GPG_0 triggered after one touch, even if another GPG instance is waiting for a second touch

When the user starts multiple GPG instances, each touch only confirms one of them, in the order they were started.
The touch detector, however, already switches back to GPG_0 ("no touch required") after the first GPG instance completes its wait.

To reproduce:

  1. Start first instance: echo | gpg --sign > /dev/null
  2. yubikey-touch-detector: [notifiers/stdout] GPG_1
  3. Start second instance: echo | gpg --sign > /dev/null
  4. touch Yubikey
  5. First instance terminates
  6. yubikey-touch-detector: [notifiers/stdout] GPG_0
  7. touch Yubikey
  8. Second instance terminates

Feature Request: Distinct Notification Data and Yubikey Serial Number Inclusion

Hi,

I'm currently using yubikey-touch-detector in conjunction with dunst for notifications. I've encountered a couple of areas where enhancements could significantly improve user experience:

  1. Inclusion of Event Type in Notification Data: Currently, all types of events trigger the same notification data. It would be highly beneficial to differentiate these events. Could we consider including the type of event in the appname or the body of the notification? This would allow for custom matching and distinct icons for each event type in dunst.

  2. Inclusion of Yubikey's Serial Number in Notifications: I have two Yubikeys connected to my PC - a Yubikey Bio for U2F and a Yubikey 5 for GPG/PIV. Being able to identify which Yubikey needs interaction (via its serial number in the notification) would be immensely helpful for users like me who use multiple devices.

These enhancements would not only improve my workflow but could also be beneficial for others in similar scenarios.

Thank you for considering these suggestions. I look forward to any feedback or discussion on these potential features.

Cheers!

No U2F events captured after boot

I use the systemd user service to run yubikey-touch-detector. I'm using NixOS 23.05 with GNOME 44.2.

When I first boot my machine, no U2F events are captured. (I don't use any other watchers.) The logs indicate successful startup of the service:

time="2023-10-06T17:24:42-04:00" level=debug msg="Starting YubiKey touch detector"
time="2023-10-06T17:24:42-04:00" level=debug msg="No 'gpg' binary in $PATH or '/home/majiir/.gnupg/pubring.kbx' could not be found. Disabling GPG and SSH watchers."
time="2023-10-06T17:24:42-04:00" level=debug msg="U2F watcher on '/dev' is successfully established"
time="2023-10-06T17:24:42-04:00" level=debug msg="HMAC watcher on '/dev' is successfully established"

However, no events are recorded in the logs, sent to the unix socket, or notified through libnotify.

The issue can be fixed by restarting the service or by unplugging and replugging the Yubikey (which is already inserted when the machine boots). In the latter case, the logs simply start recording events as usual.

Is the service missing a dependency? I noticed that it doesn't require dbus.socket, but adding that didn't fix the issue. The issue seems to be related to the watchers.

GPG_1 and endless loop when no Yubikey is plugged in

We're not quite done with the hacks yetโ€ฆ ๐Ÿ˜•

When I select an email (even an unencrypted one) in Thunderbird (v68 with Enigmail) without my Yubikey plugged in, the touch detector enters an infinite loop of generating "waiting for a touch" notifications (several per second).

-v shows that it gets stuck at GPG_1 (the loop of notifications has no individual logging, so doesn't show up of course).
Version 1.7.1 simply sent one to three pairs of GPG_1 + GPG_0 in the same second, then stayed quiet until I selected another email.

Missing GPG pubring causes error

I have no PGP keys configured on my Yubikey. Thus I get an error message about missing files everytime I run the program. Maybe you could add a flag to the config for disabling the GnuPG pubring file watch?

Stdout notifier

Thanks for this! I'm using it to display alerts via i3-nagbar with the following shell script, which is working nicely:

ALERT_PID=""

close_alert() {
    [ -n "${ALERT_PID}" ] && kill "${ALERT_PID}"
    ALERT_PID=""
}
trap close_alert EXIT INT TERM

"${YTD_BIN}" -v 2>&1 | grep --line-buffered -oP '(?<=\[notifiers/stdout\] )[^"]*' | while read -r L; do
    close_alert
    if [ "${L}" = "GPG_1" ] || [ "${L}" = "U2F_1" ]; then
        i3-nagbar -m "${L}: Press the Yubikey button" 2>/dev/null &
        ALERT_PID="$!"
    fi
done

This is too ugly for the wiki as-is though---parsing the debug output to extract messages is asking for trouble.

Admittedly I could use the systemd units and read from the unix socket like waybar-yubikey, but feels like needless complexity when my script could start it up for me. Would you be interested in a stdout notifier, activated with yubikey-touch-notifier --stdout that could go straight into a while loop like the above? Or is there reasoning behind the unix socket that I've missed?

Another minor point, "notifiers/stdout" is a misleading name for the messages, since nothing comes out of stdout. Would you accept a pull request to change it to "notifiers/stderr" to match the notifier name? "notifiers/debug" is probably more accurate, mind.

[Feature]: Support new `keyboxd` gpg pubring format

Hey ๐Ÿ‘‹

New gpg installations doesn't use pubring.kbx format since 2.4.1, and instead use keyboxd (aka sqlite db) with the $HOME/.gnupg/public-keys.d/pubring.db path.

Would be really awesome if yubikey-touch-detector gained support for keyboxd format, since newer installations are stuck without gpg detection ๐Ÿฅฒ

Thanks!

UI integration for AwesomeWM users

I use AwesomeWM and was able to work out a way to wire things up so that I could have a widget in my bar. This should be a good starting point for most people that they can tweak to their liking.

Only external dependency other than awesomewm here is openbsd-netcat which has the -U flag here.

local awful = require 'awful'
local naughty = require 'naughty'

-- First set up a watcher 
-- Calling `echo` produces a newline which the awesome callback needs to process line by line
local event_stream = [[ bash -c '
  nc -U $XDG_RUNTIME_DIR/yubikey-touch-detector.socket | while read -n5 cmd; do
    echo $cmd
  done
']]

-- Provides:
-- "yubikey"
--     event: "start" or "stop"
--     context: "GPG" or "U2F"

awful.spawn.with_line_callback(event_stream, {
  stdout = function(line)
    local event, context
    -- U2F
    if line:match("U2F") then
      context = "U2F"
      -- started waiting
      if line:match("_1") then
        event = "start"
      else
        event = "stop"
      end
    -- GPG
    else
      context = "GPG"
      -- started waiting
      if line:match("_1") then
        event = "start"
      else
        event = "stop"
      end
    end

    awesome.emit_signal("yubikey", event, context)
  end,
  stderr = function(line)
    naughty.notify({ title = "Yubikey Watcher Failure", text = line })
  end
})


-- Now create a widget that changes it's state as the events come through
-- The sky is the limit when it comes to awesome widgets, this example
-- will change the image color when yubikey needs to be touched

local wibox = require 'wibox'
local gfs = require 'gears.filesystem'
local gc = require 'gears.color'

-- SVG or PNG image works best in this example
local icon = "path/to/an/icon"

local white_icon = gc.recolor_image(icon, "#FFF")
local yellow_icon = gc.recolor_image(icon, "#FFE6B3")

local yubikey = wibox.widget {
  image = white_icon,
  widget = wibox.widget.imagebox,
  resize = true
}

-- Subscribe to signals and change state
-- We don't use the "context" argument in this example, but it's available
awesome.connect_signal("yubikey", function (event)
  local new_icon
  if event == "start" then
    new_icon = yellow_icon
  else
    new_icon = white_icon
  end
  yubikey.image = new_image
end)

return yubikey

go install not working

Hello, very cool tool, not sure if that can be local config issue but I get this


)> go install github.com/maximbaz/yubikey-touch-detector@latest
go: github.com/maximbaz/yubikey-touch-detector@latest (in github.com/maximbaz/[email protected]):
        The go.mod file for the module providing named packages contains one or
        more replace directives. It must not contain directives that would cause
        it to be interpreted differently than if it were the main module.
> go version
go version go1.21.1 linux/amd64
> go install github.com/maximbaz/[email protected]
(works)

Panic in user service on logout from desktop environment

I use the systemd user service to run yubikey-touch-detector. I'm using NixOS 23.05 with GNOME 44.2.

When I log out of GNOME, the service logs the following and crashes:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x20 pc=0x544e51]
goroutine 67 [running]:
github.com/esiqveland/notify.notifier.handleSignal({0xc00022a000, 0xc00028e540, 0xc0002ea000, 0xc000292160, 0x5d4710, 0xc0002e6c50, {0x602180, 0xc00011c000}}, 0x0)
        github.com/esiqveland/[email protected]/notification.go:274 +0x51
github.com/esiqveland/notify.notifier.eventLoop({0xc00022a000, 0xc00028e540, 0xc0002ea000, 0xc000292160, 0x5d4710, 0xc0002e6c50, {0x602180, 0xc00011c000}})
        github.com/esiqveland/[email protected]/notification.go:264 +0x109
created by github.com/esiqveland/notify.New
        github.com/esiqveland/[email protected]/notification.go:253 +0x391

This only happens when I log out from a GNOME session. If I log in or out of another TTY, the service continues to run.

The service stays in this failed state when logging back in.

systemd service doesn't/can't get correct SSH_AUTH_SOCK when using GPG as SSH agent with custom $GNUPGHOME

When setting GNUPGHOME=$XDG_STATE_HOME/gnupg, or anything except GNUPGHOME=~/.gnupg, the systemd service will never be able to get the right $SSH_AUTH_SOCK. Instead, at startup, it will print:

Nov 26 20:55:56 redacted yubikey-touch-detector[23252]: time="2023-11-26T20:55:56-08:00" level=error msg="Cannot watch SSH, the socket '/run/user/1000/gnupg/S.gpg-agent.ssh' does not exist: stat /run/user/1000/gnupg/S.gpg-agent.ssh: no such file or directory"

The cause of the problem is that GPG will change the socket path to an effectively random subdirectory of /run/user/<uid>/gpg, such as /run/user/1000/gnupg/d.ua3izggs38hms8x3fa1edxxz/S.gpg-agent.ssh (more details). Since the correct $SSH_AUTH_SOCK is set by gpg-agent in the shell rc files (.zshrc in my case) which systemd doesn't run, the service will never get the right value.

My current workaround is a janky hack. I override the systemd service and add the following:

[Service]
ExecStartPre=-/usr/bin/mkdir -p %E/yubikey-touch-detector
ExecStartPre=/usr/bin/sh -c 'echo "SSH_AUTH_SOCK=$(gpgconf --list-dirs agent-ssh-socket)\nYUBIKEY_TOUCH_DETECTOR_LIBNOTIFY=true" > %E/yubikey-touch-detector/service.conf'

Aside from GPG fixing it upstream, the ideal fix would be for yubikey-touch-detector to run gpgconf --list-dirs agent-ssh-socket once at the start, and fall back to that. If for some reason the hash changes (which is possible, although it shouldn't happen during normal use - by the time I finished setting up my yubikey I had 9 subdirs), then it would only take a systemctl --user restart yubikey-touch-detector to fix.

Desktops supported

I assume this only support Linux ?
I need MAc and Windows support to make it work with my desktop apps

Add option to disable GPG detection

There should be an option to disable GPG detection.

As noted in #22 (comment), GPG detection is a bit hacky. I am not a GPG user, so I was surprised to find that enabling yubikey-touch-detector caused my Yubikey LED to stay on long after each touch. It turns out that merely opening the GNOME Passwords and Keys app creates ~/.gnupg/pubring.kbx, which yubikey-touch-detector then uses as evidence that the user wants the GPG check.

For consistency, it would be great to have an option for each detector method.

Notifications with additional information?

Hey,
it's me again. I was just wondering if it would be possible to show any additional information within the notification? More about the context or rather who/what is triggering the request. Because I have some background tools which use gpg. If I always just touch the YubiKey without knowing for what, this could simply become a security leak. At the moment I try to send notifications myself to inform myself which application is triggering the action (after all that's isn't much safer and opens for other opportunities).
Anyway, I took a glance at your implementation, but I must admit that I wasn't able to determine which eventual additional information you can actually get. But it would be amazing if there would be some.
Thanks for sharing!

Gracefully handle missing `gpg` in PATH

As described in #43, it is possible for a user to have a ~/.gnupg/pubring.kbx file without being a GPG user.

When yubikey-touch-detector finds the keyring, it enables GPG detection. Then, when there is a touch event, yubikey-touch-detector spams this its log:

ERRO[2023-09-19T21:15:28-04:00] exec: "gpg": executable file not found in $PATH 
ERRO[2023-09-19T21:15:28-04:00] exec: "gpg": executable file not found in $PATH 
ERRO[2023-09-19T21:15:28-04:00] exec: "gpg": executable file not found in $PATH 
ERRO[2023-09-19T21:15:28-04:00] exec: "gpg": executable file not found in $PATH 
ERRO[2023-09-19T21:15:28-04:00] exec: "gpg": executable file not found in $PATH

How to circumvent `-buildmode=pie not supported on OpenBSD`

Admittedly, I know next to nothing in Go-lang, not even 'hello, world'. I know this is primarily designed to be run within a Linux environment as a systemd user level service, but if I could get it to build then I can always run it on startup with i3, or write up a rc.d file for it. That scenario would be awesome.

Feature Request: Configurable notification text

It's nice that I get a notifications now when requesting authorization.

However, it would be cool to have the ability to customize that message as well.

I'm not a golang programmer but I might be able to implement something.
Looks like this line would need the configuration.

Possibly pulling from the systemd config file? Not sure.

Happy Holidays!

Add ability to check if touch is pending by external process

To allow easier integration with other plugin systems, for example with https://docs.xfce.org/panel-plugins/xfce4-genmon-plugin, it would be nice if one could for example send a command to UNIX socket to get the current state and act accordingly. That would allow polling periodically for state, which is simpler than having a continuously running process.

With https://docs.xfce.org/panel-plugins/xfce4-genmon-plugin example, the difference is writing your Panel Plugin in C vs making a bash command echoing specific icon conditionally, which is a big difference.

Notification can't be closed on qtile.

When I use the detector under qtile, it works fine, but it can't close the notification. The error is:

ERRO[2022-11-06T16:47:36+01:00] Cannot close notification: The service interface raised an error: list index out of range.
['  File "/f/.local/share/virtualenvs/qtile/lib/python3.10/site-packages/dbus_next/message_bus.py", line 712, in _process_message\n    handler(msg, send_reply)\n', '  File "/f/.local/share/virtualenvs/qtile/lib/python3.10/site-packages/dbus_next/message_bus.py", line 731, in handler\n    result = method.fn(interface, *args)\n', '  File "/f/.local/share/virtualenvs/qtile/lib/python3.10/site-packages/libqtile/notify.py", line 88, in CloseNotification\n    self.manager.close(nid)\n', '  File "/f/.local/share/virtualenvs/qtile/lib/python3.10/site-packages/libqtile/notify.py", line 203, in close\n    notif = self.notifications[nid]\n']

The file mentioned in the stacktrace is https://github.com/qtile/qtile/blob/master/libqtile/widget/notify.py.

My knowledge about python (and coding in general) is very limited, so I would like to ask if you see any way it can be a detector's fault, or should I go directly to the qtile team?

U2F notification does not work

Hi Maxim, you may remember me from other threads :)

Unfortunatelly, U2F notification does not work for me. GPG notifications work fine though.
I opened three terminals

Terminal1:

> sudo ls
Downloads            Desktop                   Documents

Terminal2:

> inotifywait -m /dev/hidraw5 /dev/hidraw6 /run/user/1000/pam-u2f-authpending
Setting up watches.
Watches established.
/run/user/1000/pam-u2f-authpending OPEN 
/dev/hidraw5 OPEN 
/dev/hidraw5 CLOSE_WRITE,CLOSE 
/dev/hidraw6 OPEN 
/dev/hidraw6 CLOSE_WRITE,CLOSE 
/dev/hidraw6 OPEN 
/dev/hidraw6 MODIFY 
/dev/hidraw6 ACCESS 
/dev/hidraw6 MODIFY 
/dev/hidraw6 MODIFY 
/dev/hidraw6 MODIFY 
/dev/hidraw6 ACCESS 
/dev/hidraw6 MODIFY 
/dev/hidraw6 MODIFY 
/dev/hidraw6 MODIFY 
/dev/hidraw6 ACCESS 
/dev/hidraw6 MODIFY 
/dev/hidraw6 MODIFY 
/dev/hidraw6 MODIFY 
/dev/hidraw6 ACCESS 
/dev/hidraw6 MODIFY 
/dev/hidraw6 MODIFY 
/dev/hidraw6 MODIFY 
/dev/hidraw6 ACCESS 
/dev/hidraw6 MODIFY 
/dev/hidraw6 MODIFY 
/dev/hidraw6 MODIFY 
/dev/hidraw6 ACCESS 
/dev/hidraw6 ACCESS 
/dev/hidraw6 CLOSE_WRITE,CLOSE 
/run/user/1000/pam-u2f-authpending CLOSE_NOWRITE,CLOSE 

Terminal3:

> yubikey-touch-detector -v
DEBU[2020-04-13T13:15:53-07:00] Starting YubiKey touch detector              
DEBU[2020-04-13T13:15:53-07:00] SSH watcher is successfully established      
DEBU[2020-04-13T13:15:53-07:00] GPG watcher is successfully established      
DEBU[2020-04-13T13:15:53-07:00] U2F watcher on '/dev' is successfully established 

Do you have any means to increase verbosity of the debug output?
What additional information about my environment do you need?

Install on Debian

Using the next Debian 12.

# untar to some place, like /tmp
sudo mv /tmp/yubikey-touch-detector-1.10.0-linux64/yubikey-touch-detector /usr/bin/yubikey-touch-detector
mv /tmp/yubikey-touch-detector-1.10.0-linux64/yubikey-touch-detector.service ~/.config/systemd/user/yubikey-touch-detector.service
mv /tmp/yubikey-touch-detector-1.10.0-linux64/yubikey-touch-detector.socket ~/.config/systemd/user/yubikey-touch-detector.socket

# Config
# See: https://superuser.com/a/365918/609233
mkdir -v ${XDG_CONFIG_HOME:-$HOME/.config}/yubikey-touch-detector/
nano ${XDG_CONFIG_HOME:-$HOME/.config}/yubikey-touch-detector/service.conf
# Enable desktop notifications: https://github.com/maximbaz/yubikey-touch-detector#configuring-the-app

# Register service and start it
systemctl --user daemon-reload
systemctl --user enable --now yubikey-touch-detector.service
# Check running
systemctl --user status yubikey-touch-detector.service
# Cleanup
rm -r /tmp/yubikey-touch-detector-1.10.0-linux64/

You can add this to the README

Mac Support

Has anyone been successful in building this on OSX? I receive the following error:

Great project btw!

>go get -u github.com/maximbaz/yubikey-touch-detector
# github.com/maximbaz/yubikey-touch-detector/detector
../../../golang/src/github.com/maximbaz/yubikey-touch-detector/detector/gpg.go:19:50: undefined: notify.InOpen
../../../golang/src/github.com/maximbaz/yubikey-touch-detector/detector/gpg.go:19:65: undefined: notify.InDeleteSelf
../../../golang/src/github.com/maximbaz/yubikey-touch-detector/detector/gpg.go:19:86: undefined: notify.InMoveSelf
../../../golang/src/github.com/maximbaz/yubikey-touch-detector/detector/gpg.go:33:9: undefined: notify.InOpen
../../../golang/src/github.com/maximbaz/yubikey-touch-detector/detector/u2f.go:24:54: undefined: notify.InOpen
../../../golang/src/github.com/maximbaz/yubikey-touch-detector/detector/u2f.go:24:69: undefined: notify.InCloseWrite
../../../golang/src/github.com/maximbaz/yubikey-touch-detector/detector/u2f.go:24:90: undefined: notify.InCloseNowrite
../../../golang/src/github.com/maximbaz/yubikey-touch-detector/detector/u2f.go:24:113: undefined: notify.InDeleteSelf
../../../golang/src/github.com/maximbaz/yubikey-touch-detector/detector/u2f.go:24:134: undefined: notify.InMoveSelf
../../../golang/src/github.com/maximbaz/yubikey-touch-detector/detector/u2f.go:38:9: undefined: notify.InOpen
../../../golang/src/github.com/maximbaz/yubikey-touch-detector/detector/u2f.go:38:9: too many errors

Help - parse socket output and send to IPC

Hey,
thanks for this great tool!
There are already a couple of status bars supported. I now like to make it work with polybar as well. The idea is pretty simple, connect to the socket of yubikey-touch-detector, parse output for each event and covert it into messages that you can put onto a FIFO. This makes use of polybars custom modules via IPC (short docs here. The component would look like that:

[module/yubikey-touch]
type = custom/ipc

hook-0 = echo
hook-1 = echo "key-icon"

format-foreground = #ffffff
format-background = #ff0000

So when hook 0 (which is the initial one) gets triggered the component is empty, end for hook 1 it shows a nice icon and has catchy colors.
Now I need to listen to the output of the socket. When it matches GPG_1, U2F_1 or MAC_1 it should trigger hook 1 and when GPG_0, U2F_0 or MAC_0 trigger hook 0.
My approach was like this ncat --recv-only --unixsock $XDG_RUNTIME_DIR/yubikey-touch-detector.socket | grep 0 | polybar-msg hook yubikey-touch 1 (and the same for 1).
Anyways, while I can listen to the socket and read the output successfully. But the grep does not work anymore. I guess because grep works on lines. So I tried the stream editor and also attempt to parse the number to make it re-used for the hook number: ncat --recv-only --unixsock ./yubikey-touch-detector.socket | sed -r 's/GPG_([0,1])/\1/g'. But that does not work as well.

I'm sorry to bother you with such issues, but do you have some hints how to do this?

PS:
The idea was to make this then a systemd service unit that is triggered by your socket unit and gets the socket passed as template argument.

Not detecting U2F from WebAuthn?

I am unsure if i am doing something wrong here, so please bear with me.

I started the application using the command

yubikey-touch-detector -v

and i got the output here:

DEBU[2020-03-07T11:11:22-05:00] Starting YubiKey touch detector
DEBU[2020-03-07T11:11:22-05:00] SSH watcher is successfully established
DEBU[2020-03-07T11:11:22-05:00] GPG watcher is successfully established
DEBU[2020-03-07T11:11:22-05:00] U2F watcher is successfully established

Then i went here and typed a random username and clicked register, then yubikey started flashing and the website showed a screen for me to touch the yubikey, however the output of the terminal didnt change.

I am trying to integrate this with waybar, and i used the same script listed here

however when running this script i got a error saying the following :

waybar-yubikey
nc: invalid option -- 'U'
Try `nc --help' for more information.

I then made a modification to make -U lowercase and be -u but then i got this error:

Error: Couldn't resolve host "/run/user/1000/yubikey-touch-detector.socket"

I have no idea how to continue, i went to that url in the browser and the socket file does exist.. so i have no idea why netcat isn't able to connect to it. Any help?

.lk# files left in .gnupg

I started to use this project a couple of days ago (really liking it). Now my .gnupg folder is getting filled with files like .lk#.......

I found https://unix.stackexchange.com/questions/246121/files-starting-with-lk0xb-in-gnupg-directory-what-are-they/246129#246129 that explains that this is lock files and that they're supposed to be cleaned up.

It seems to happen on every authentication.

Is this something yubikey-touch-detector should clean up or could it be something with my GPG or machine setup?

Long options in help output

I don't want to be picky, but shouldn't the output include double dashes for the long options? Maybe also add --verbose as the long option alternative for -v.

Usage of yubikey-touch-detector:
  --gpg-pubring-path string
    	path to gpg's pubring.kbx file
  --libnotify
    	show desktop notifications using libnotify
  --verbose | -v
        print verbose output
  --version
    	print version and exit

However, it looks like every option works with one or two dashes.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.