$ sudo lsinput

/dev/input/event5
 bustype : BUS_USB
 vendor : 0x46e
 product : 0x52cb
 version : 272
 name : "BTC USB Multimedia Keyboard"
 phys : "usb-0000:00:06.1-4.3/input1"
 uniq : ""
 bits ev : EV_SYN EV_KEY EV_MSC

/dev/input/event6
 bustype : BUS_USB
 vendor : 0x458
 product : 0x5e
 version : 272
 name : "KYE ADNS6000 Optical Mouse"
 phys : "usb-0000:00:06.1-4.4/input0"
 uniq : ""
 bits ev : EV_SYN EV_KEY EV_REL EV_MSC

Use the name to find system path of the device:

$ udevadm info -q path -n /dev/input/event5
/devices/pci0000:00/0000:00:06.1/usb2/2-4/2-4.3/2-4.3:1.1/input/input5/event5

Make a test run:

$ udevadm test /devices/pci0000:00/0000:00:06.1/usb2/2-4/2-4.3/2-4.3:1.1/input/input5/event5
(...)
udev_device_update_db: unable to create temporary db file '/run/udev/data/c13:69.tmp': Permission denied
ACTION=add
DEVLINKS=/dev/input/by-id/usb-BTC_USB_Multimedia_Keyboard-event-if01 /dev/input/by-path/pci-0000:00:06.1-usb-0:4.3:1.1-event
DEVNAME=/dev/input/event5
DEVPATH=/devices/pci0000:00/0000:00:06.1/usb2/2-4/2-4.3/2-4.3:1.1/input/input5/event5
ID_BUS=usb
ID_INPUT=1
ID_INPUT_KEY=1
ID_MODEL=USB_Multimedia_Keyboard
ID_MODEL_ENC=USB\x20Multimedia\x20Keyboard
ID_MODEL_ID=52cb
ID_PATH=pci-0000:00:06.1-usb-0:4.3:1.1
ID_PATH_TAG=pci-0000_00_06_1-usb-0_4_3_1_1
ID_REVISION=0110
ID_SERIAL=BTC_USB_Multimedia_Keyboard
ID_TYPE=hid
ID_USB_DRIVER=usbhid
ID_USB_INTERFACES=:030101:030000:
ID_USB_INTERFACE_NUM=01
ID_VENDOR=BTC
ID_VENDOR_ENC=BTC
ID_VENDOR_ID=046e
MAJOR=13
MINOR=69
SUBSYSTEM=input
UDEV_LOG=6
USEC_INITIALIZED=4552168
XKBLAYOUT=us
XKBMODEL=pc105
XKBOPTIONS=
XKBVARIANT=

Look data that is specific to device you want to customize. ID_TYPE=hid is too general, but perhaps ID_VENDOR_ID or ID_MODEL_ID. Sometime there is some tip about device type like ID_INPUT_TOUCHPAD=1. If the data seems too general, it may be better to attach to parent device, run the command again without the last “event” part:

$ udevadm test /devices/pci0000:00/0000:00:06.1/usb2/2-4/2-4.3/2-4.3:1.1/input/input5

Still, try to find something as close to the end of the chain as possible. Another way worth of trying is to run udevadm info:

$ udevadm info -a -p
/devices/pci0000:00/0000:00:06.1/usb2/2-4/2-4.3/2-4.3:1.1/input/input5/event5

Finding the right filter rules seems to be always most difficult for me… Create a new file in /etc/udev/rules.d starting with 2-digit number (this is rule’s priority, I suggest a large one to keep the rule close to the end of the chain). My rules for detecting a Apple Bluetooth keyboard and  a touchpad are:

ACTION!="add|change", GOTO="apple_kbd_end"
SUBSYSTEM!="input", GOTO="apple_kbd_end"
KERNEL!="event[0-9]*", GOTO="apple_kbd_end"

ATTRS{address}=="60:fb:42:02:12:a9", RUN+="keymap $name apple"
ENV{ID_INPUT_TOUCHPAD}=="1", RUN+="/home/test/bin/send-command hostname slowgestures"

<span style="font-family: 'Courier 10 Pitch', Courier, monospace; font-size: 13px; font-style: normal; line-height: 1.5;">LABEL="apple_kbd_end"</span>

So I’m using Bluetooth address for keyboard and ID_INPUT_TOUCHPAD for the touchpad. When it is added to system, a script “send-command” will be run. After editing the file, save it and run the udevadm test again:

$ udevadm test /devices/pci0000:00/0000:00:06.1/usb2/2-4/2-4.3/2-4.3:1.1/input/input5/event5

USEC_INITIALIZED=150940194993
run: '/home/test/bin/send-command hostname slowgestures'

Check the run command is there. If not, change the rules and try again. If it worked, run one last command to inform the udev daemon about the changes:

sudo udevadm control --reload-rules

That’s it. Now it’s up to you to write the event handlers.

What is this?

This authentication method uses 2 keys: private and public. Let’s use example:

• S is some remote server
• C is your laptop

The public key is put on server. It can be shared with anyone, it is of no use to anyone except the owner of the private key.

The private key is kept in safe place on laptop. During authentication server S verifies whether the secret key from C matches the public key on S. If so, user is allowed to log in. It is important to remember, keeping the private key secret is just as important as guarding your password.

Preparation

Simpler than it used to be… To generate the new key pair:

ssh-keygen

and follow defaults. There will be a warning if the key already exists. For simplicity don’t specify a password (I will write how to use a password protected key without having to type too much another time).

Now, to copy the public key to remote sever run:

ssh-copy-id server

Enter the password once more, and try:

ssh server

Congratulations! And remember to protect the key!