linux

IgnoreUnknown not working as expected?

Michał MargulaLeave a comment
Posted in linux macTagged

Sometimes we need to share our ~/.ssh/config with other host (or even a docker container) that might not be understanding all the options. The usual case is with UseKeychain on MacOS that won’t work on Linux. To fix that we add IgnoreUnknown UseKeychain and move on.

If you have multiple Host entries in the config, it might happen you will need for multiple entries. But adding it per host will just confuse SSH and you will end up with errors even if IgnoreUnknown is used for each of that.

Solution to this is to move IgnoreUnknown to the top of the config file, outside any host scope. So instead of

Host alpha
  IgnoreUnknown UseKeychain
  User alchemyx
Host beta
  IgnoreUnknown UseKeychain
  User root

just use

IgnoreUnknown UseKeychain
Host alpha
  User alchemyx
Host beta
  User root

Smokeping with NGINX

Michał MargulaLeave a comment
Posted in linuxTagged

My humble little webserver (which hosts used to host this site) is using NGINX. It works exceptionally well for my needs. I also have a Smokeping running on it all the time to monitor my ISP connectivity.

As link quality has deteriorated recently I wanted to review relevant graphs. It turns out that Smokeping is still using CGI in 2020 (d’oh). NGINX does not support it so the idea was to spin up CGI to FastCGI bridge and serve the content via fastcgi_pass. To have it working on Ubuntu 18.04 LTS you need to add following lines to your virtual host definition in /etc/nginx/sites-enabled:

location /smokeping {
        alias /usr/share/smokeping/www;
        try_files $uri $uri/ =404;

        location /smokeping/smokeping.cgi {
                fastcgi_pass  localhost:9999;

                fastcgi_param QUERY_STRING    $query_string;
                fastcgi_param REQUEST_METHOD  $request_method;
                fastcgi_param CONTENT_TYPE    $content_type;
                fastcgi_param CONTENT_LENGTH  $content_length;
        }

        allow 192.168.0.0/24;
        deny all;
}

Please note it also limits access to your LAN only (assuming it is 192.168.0.0/24). Then install libfcgi-bin

apt update && apt install libfcgi-bin

And spin up the bridge from the unprivileged user that has write access to /var/lib/smokeping/:

sudo -u smokeping -- /usr/bin/cgi-fcgi -start -connect 127.0.0.1:9999 /usr/share/smokeping/smokeping.cgi

And that’s all. I use the web frontend rarely so I spin it manually. You can make it persistent using /etc/rc.local or systemd if you need it more often.

Using SoloKey on vanilla Ubuntu

Michał MargulaLeave a comment
Posted in linuxTagged

It has been almost a year since last time I posted here so today we will have a quick one. I recently bought a SoloKey U2F key. It is a much cheaper and opensorce replacement for YubiKey (which is also a great product – I had a chance to use it for almost 2 years and it was flawless). In vanilla Ubuntu 18.04 when you plugin the key it gets detected correctly:

[Tue Feb 19 21:13:28 2019] usb 1-1: new full-speed USB device number 8 using xhci_hcd
[Tue Feb 19 21:13:28 2019] usb 1-1: New USB device found, idVendor=0483, idProduct=a2ca
[Tue Feb 19 21:13:28 2019] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[Tue Feb 19 21:13:28 2019] usb 1-1: Product: Solo
[Tue Feb 19 21:13:28 2019] usb 1-1: Manufacturer: Solo Keys
[Tue Feb 19 21:13:28 2019] usb 1-1: SerialNumber: 0123456789ABCDEF
[Tue Feb 19 21:13:28 2019] hid-generic 0003:0483:A2CA.0008: hiddev1,hidraw3: USB HID v1.11 Device [Solo Keys Solo] on usb-0000:00:14.0-1/input0

Unfortunately permissions for device are incorrect and the key won’t be accessible from the browser:

$ ls -la /dev/hidraw*
crw------- 1 root root 243, 0 lut 19 21:03 hidraw0
crw------- 1 root root 243, 1 lut 19 21:03 hidraw1
crw------- 1 root root 243, 2 lut 19 21:03 hidraw2
crw------- 1 root root 243, 3 lut 19 21:13 hidraw3

To fix it we need a simple udev rule in /etc/udev/rules.d/90-solokey.rules:

KERNEL=="hidraw*", SUBSYSTEM=="hidraw", MODE="0664", GROUP="plugdev", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="a2ca"

And then reload the udev rules:

sudo udevadm control --reload-rules

Thanks to that rule it will have group set to plugdev and read/write permissions for that device. By default user created in Ubuntu is a member of such group so it will work out of the box:

$ id
uid=1000(alchemyx) gid=1000(alchemyx) grupy=1000(alchemyx),4(adm),20(dialout),24(cdrom),27(sudo),30(dip),46(plugdev),116(lpadmin),126(sambashare),128(kismet)

Now you can test it by going to demo.yubico.com using Google Chrome. Click Next on first page and allow access to the key. The LED on SoloKey should turn amber and after clicking its hardware button it will get registered correctly.

If you want to do the same from the Firefox you need to reconfigure it first. Open about:config URL and confirm that you accept the risk. Find security.webauth.u2f there and flip it to True.