[Howto] Remapping buttons with xbindkeys and xte

TuxSometimes you buy devices like a mouse or a keyboard which provide additional buttons for special functions. Or which have buttons which do not behave as expected. In such cases the button actions can be mapped to other functions, or even to other buttons.

I recently bought a Logitech M705 mouse which works almost perfectly. However, there is one nagging bug: the middle mouse button does not trigger the usual event “mouseclick two” which is interpreted as pressing the middle button, the scroll wheel which is crucial for example browsing the web. Nothing happens.

In such cases the first step is to see if the operating system receives any input at all. Fire up a shell and start the program xev. It opens a small, white window where you can move your cursor to. As soon as the cursor enters the window, you will see a lot of log data on the shell: xev shows you all X events, thus all data you enter via keyboard or mouse.

In my case I pressed the middle button, and saw:

ButtonPress event, serial 40, synthetic NO, window 0x5800001,
    root 0xc7, subw 0x5800002, time 19610234, (46,38), root:(1784,61),
    state 0x10, button 6, same_screen YES
[...]
ButtonRelease event, serial 40, synthetic NO, window 0x5800001,
    root 0xc7, subw 0x5800002, time 19610234, (46,38), root:(1784,61),
    state 0x210, button 6, same_screen YES

The interesting part is that the button was not interpreted as “button 2” as I would have expected, but as “button 6”. That’s not what I expected, and thus the button must be remapped to the event “button 2”.

Mapping of keys and buttons can be done via xbindkeys: in case of KDE I created a symlink to start the program at each startup:

ls -la ~/.kde/env/xbindkeys 
lrwxrwxrwx 1 liquidat users 18 Aug  1 10:56 .kde/env/xbindkeys -> /usr/bin/xbindkeys

xbindkeys reads its configuration from ~/.xbindkeysrc, so that’s the place where we need to configure the actual mapping. The syntax is:

#    "command to start"
#       associated key

The most interesting part of the mapping is: how to trigger the action “button 2”? That is done by the program xte which generates fake input. Thus the final configuration is:

"xte 'mouseclick 2'"                                                                                                                                                                                           
  b:6  

And you are done. Pressing the mouse button 6 on the Logitech M705 now launches the mouseclick 2.

However, as stated correctly by the comments below, this is just an intermediate solution! A long time solution is to fix the mapping in evdev, the Linux input handling.

[Short Tip] Use SSH agent forwarding on remote servers

920839987_135ba34fff
When you administrate machines it sometimes makes sense to forward your SSH agent information from your client A to the server B. Using agent forwarding you can use the authentication keys from client A on server B to for example properly authenticate on server C – without the need to copy your private SSH key to server B. One common example in my case is that I sometimes need to access Gitolite/Github repositories on server B but I do not want to copy my SSH key there.

Keep in mind that you previously have to add the wanted SSH key on client A via ssh-add!

$ ssh-add -c
Identity added: /home/liquidat/.ssh/id_rsa (/home/liquidat/.ssh/id_rsa)
The user must confirm each use of the key
$ ssh -A server_b.example.net
liquidat@server_b.example.net's password: 
Last login: Fri May 24 17:11:17 2013 from somewhereovertherainbow.example.com
$ ssh git@git.example.com info
hello liquidat, this is git@git.example.com running gitolite3 3.5.1-1.el6 on git 1.7.1

[...]

(Thanks to Evgeni for reminding me of the ‘-c’ flag.)

[Howto] Changing the expiry date of GPG keys

920839987_135ba34fff
GnuPG keys can have an expiry date. When the key expires, it cannot be used to encrypt data anymore, and thus is a good way to enforce security measures. However, what most people does not seem to know is that this expiry date can be changed quite easily.

Setting an expiry date for a GPG key is usually a good thing: it makes sure that even if you forget the password and do not have a revocation certificate the key will not be valid at some point in the future. Additionally it might force users to replace keys ever so often to enforce specific security measures. Last but not least it forces the key owner to think about his or her own GPG infrastructure and if changes are needed.

Still, there might be times where it makes sense to change the expiry date – if only because you realized that your GPG keys are all fine.

First, you need to know the key ID, in this example ABCDEF12:

$ gpg --list-keys liquidat@example.com
pub   2048R/ABCDEF12 2012-09-10 [expires: 2032-09-10]
uid                  liquidat <liquidat@example.com>
sub   2048R/BCDEF123 2012-09-10 [expires: 2032-09-10]]

With that ID at hand you can now edit the key:

gpg --edit-key ABCDEF12
gpg (GnuPG) 1.4.12; Copyright (C) 2012 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Secret key is available.

pub  2048R/ABCDEF12  created: 2012-09-10  expires: 2013-09-10  usage: SC  
                     trust: ultimate      validity: ultimate
sub  2048R/BCDEF123  created: 2012-09-10  expires: 2013-09-10  usage: E   
[ultimate] (1). liquidat <liquidat@example.com>

gpg>

As you see this key is going to expire in fall 2013. The gpg> indicates a prompt, so you are basically at a gpg specific shell. So, let’s actually change the expiry date:

gpg> expire
Changing expiration time for the primary key.
Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years
Key is valid for? (0) 3y
Key expires at Fri May  6 15:45:42 2016 CEST
Is this correct? (y/N) y

You need a passphrase to unlock the secret key for
user: "liquidat <liquidat@example.com>"
2048-bit RSA key, ID ABCDEF12, created 2012-09-10

The passphrase is usually queried by standard means, so on a desktop systems a pop up windows should come up asking you for the passphrase.

Afterwards, list the key again to check the new expiry date:

gpg> list
pub  2048R/ABCDEF12  created: 2012-09-10  expires: 2016-09-10  usage: SC  
                     trust: ultimate      validity: ultimate
sub  2048R/BCDEF123  created: 2012-09-10  expires: 2013-09-10  usage: E   
[ultimate] (1). liquidat <liquidat@example.com>

gpg>

As you see, the expiry date has only changed for the first key, but not for the pub key. The edit procedure is always for one key only. Thus, change the focus from the first key, called “key 0”, to the sub key, “key 1”. A star sign * will indicate the focus on the subkey:

gpg> key 1
pub  2048R/ABCDEF12  created: 2012-09-10  expires: 2016-09-10  usage: SC  
                     trust: ultimate      validity: ultimate
sub*  2048R/BCDEF123  created: 2012-09-10  expires: 2013-09-10  usage: E   
[ultimate] (1). liquidat <liquidat@example.com>

gpg> expire

Changing expiration time for a subkey.
Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years
Key is valid for? (0) 3y
Key expires at Fri May  6 15:45:42 2016 CEST
Is this correct? (y/N) y

You need a passphrase to unlock the secret key for
user: "liquidat <liquidat@example.com>"
2048-bit RSA key, ID BCDEF123, created 2012-09-10

gpg> list
pub  2048R/ABCDEF12  created: 2012-09-10  expires: 2016-09-10  usage: SC  
                     trust: ultimate      validity: ultimate
sub  2048R/BCDEF123  created: 2012-09-10  expires: 2016-09-10  usage: E   
[ultimate] (1). liquidat <liquidat@example.com>

As you see, you are done, both dates are changed now. The changes finally need to be saved:

gpg> save

And, last but not least, don’t forget to upload the updated public key to the key servers:

$ gpg --keyserver pgp.mit.edu --send-keys ABCDEF12
gpg: sending key ABCDEF12 to hkp server pgp.mit.edu

[Short Tip] Copy SSH-Identity

920839987_135ba34fffIf you regularly shh to a specific server, it is handy to copy the public part of your ssh key to the other server to avoid putting in the login password all the time. But instead of manually picking your public key, invoking scp manually to throw it to the server and calling echo/cat to attach it to

~/.ssh/authorized_keys

you can use one handy little command:

# ssh-copy-id liquidat@mymachine.de
liquidat@mymachine.de's password:
Now try logging into the machine, with "ssh 'liquidat@mymachine.de'", and check in:

~/.ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.

If you need to use a different port the command is a bit different than you might expect:

# ssh-copy-id "liquidat@mymachine.de  -p 1234"