<--
Some bits & bobs
Here lives some miscellaneous things I reference one or one hundred
times and figure they should be gathered somewhere.
wpa_supplicant
Frequently forgotten usage of the wpa_cli
tool
> scan
...
<3>CTRL-EVENT-SCAN-RESULTS
> scan_results # run once above event appears
bssid / freq / sig lvl / flags / ssid
...
> add_network
#
> set_network # ssid "network"
> set_network # psk "psswd"
# or if no password:
> set_network # key_mgmt NONE
> enable_network #
> save_config
GPG key signing with Git
Sometime ago I spent hours on a new system on this. When signing a
commit, this error would appear
gpg: skipped "Foo Bar ": No secret key[GNUPG:] INV_SGNR 9 Foo Bar [GNUPG:] FAILURE sign 17
gpg: signing failed: No secret key
After much searching I came up empty handed. Finally, one thing
stood out. The name and email in ~/.gitconfig
must
match exactly to the name and email associated with the GPG key
$ gpg --list-secret-keys --keyid-format=long
/home/foo/.gnupg/pubring.kbx
-----------------------------
sec rsa4096/FC53C827D09C7050 2019-03-24 [SC]
ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890
uid [ultimate] Foo Bar
ssb rsa4096/2EE67124D597BB00 2019-03-24 [E]
$ head -n 4 .gitconfig
[user]
name = Foo Bar
email = Foo_Bar@baz
signingkey = FC53C827D09C7050
SSH agent for password-less login
I have four machines I frequently log in to and from via SSH. Typing
in a password every time is tiresome and a password-less key is not
an option. A solution is an SSH agent running in the background, which
prompts for a password once at log in, and stores it for the duration
of the session (until reboot). The following can live in your shell's
startup file (eg. ~/.zshrc
)
if [ ! -S ~/.ssh/ssh_auth_sock ]; then
eval "$(ssh-agent)"
ln -sf "$SSH_AUTH_SOCK" ~/.ssh/ssh_auth_sock
fi
export SSH_AUTH_SOCK=~/.ssh/ssh_auth_sock
ssh-add -l > /dev/null || ssh-add
Then, just copy the needed key between machines with ssh-copy-id -i ~/.ssh/id_xxx.pub name@host
Configuration file manager
Across the aforementioned four machines, I also have various configuration
files (dotfiles) that I like to keep track of for the sake of backing
them up incase of data loss. I use yadm
to achieve this. Mostly for it's ease of use (yadm is quite simply
an alias for git) and minimal system footprint, which consists mostly
of a git directory living out of sight in ~/.local/share/yadm/repo.git
.
Since it's just Git under the hood, a standard .gitignore
file can be used to ignore which ever files you choose in your home directory.
By default, yadm only manages files within your home directory. While not
conventional, it can also be used to track system-level files by creating
an alias like sysyadm="sudo yadm --yadm-dir /etc/yadm --yadm-data /etc/yadm/data"
,
then used like normal.
# sysyadm init -w /
# sysyadm add foo.conf
# sysyadm commit -m "foo"
Hardware security key for authentication on Linux
Typing in a rather long password each time I log into my computer
or need to complete a privileged task can be bothersome. A couple
years ago I came across solokeys,
which are fully open source hardware and firmware security keys. I
chose to build the Solo 1
(or five because that's the MOQ from most PCB manufacturers). Note,
at the time of writing this, the solo1-cli
tool is currently broken with the latest FIDO2 library, meaning
it must be installed explicitly at 0.9.3.
$ pip3 install solo1
$ pip3 install fido2==0.9.3
After building, I didn't use it much, as many services don't support
security keys quite yet, or required a paid subscription (I'm looking
at you, Bitwarden). Come a few months ago, I found Yubico's PAM for U2F.
To use this, first ensure the CONFIG_HIDRAW
and
CONFIG_USB_HIDDEV
options are set in your kernel.
Next, obtain the module via package manager or compiling from source
and generate the authorisation mapping with your key inserted. The
created directory must be named Yubico
, even if not
using a Yubico key. It can be overridden in util.h
if you so choose.
$ mkdir ~/.config/Yubico
$ pamu2fcfg > ~/.config/Yubico/u2f_keys
Enter PIN for /dev/hidraw2:
Assuming all has been successful, you can configure PAM services
to use the device. The following configures doas to utilise the
U2F module in the /etc/pam.d/doas
file. The same line
can be added in other files where needed (eg. display manager,
system-local-login
, etc.)
auth sufficient pam_u2f.so cue pinverification=0
auth include system-auth
...
Above, sufficient indicates that authentication from the device
alone is enough to fully authenticate. Use required instead
if you want both password and device authentication to be required.
cue simply displays a prompt to press the button on the device
when needed to authenticate. pinverification=0 disables the need
to entre the passphrase associated with your security key. Note, this
means your system can be accessed only with your key, and no password entry
of any type. Set the parameter to 1 if you'd like otherwise.