Recently, I decided to give FIDO2-backed ssh keys a go for work and personal use. The theoretical benefits of keeping your private keys secure and irretrevable are pretty compelling in certain use cases.
Background on the Issues with Yubikeys and SSH on MacOS
With modern versions of OpenSSH (8.3+), you can use SSH keys stored in a modern Yubikey that supports FIDO2 (specifically FIDO 2.1 for credProtect, which early versions of Yubikey 5 did not support). This allows you to use the key in an attached Yubikey to authenticate to remote SSH servers, including Linux, GitHub and anything that supports ed25519-sk and ecdsa-sk keytypes (essentially ed25519 and ecdsa keys in a Yubikey or other hardware device). For their own reasons, Apple has the MacOS bundled versions of OpenSSH (including ssh-keygen and ssh-agent) built with support for this disabled (including as of November 2024 with MacOS Sequoia 15.1.1). We can get around this by installing the clients via Homebrew.
I’ve setup this website on a FreeBSD droplet on Digital Ocean. I want to start off by saying that DO is a wicked cool service that is both relatively cheap, quick, and slick.
However, there’s currently a problem with their FreeBSD droplets. I’m getting some bad packet loss which is killing the performance of the service, which is why the website is taking so long to load. It’s a known issue that they’re working on but they can’t/won’t give me a timeframe. They’ve given me a free 3 month credit, so I’m going to wait it out for another month or so before switching to an Ubuntu image.
1
2
3
4
5
6
|
$ sudo -s
Password:
Your mind just hasn't been the same since the electro-shock, has it?
Password:
stty: unknown mode: doofus
Password:
|
:-D
I’m currently on a VIA train heading home. Since Angelo bought the wifi service for the day and then just went to sleep, he let me use it. It’s almost useable (AJAX tends barf on it). It’s uplink is via satellite.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
hylarides:~ hylaride$ ping www.google.ca
PING www.l.google.com (64.233.161.104): 56 data bytes
64 bytes from 64.233.161.104: icmp_seq=0 ttl=240 time=1031.102 ms
64 bytes from 64.233.161.104: icmp_seq=1 ttl=240 time=1131.279 ms
64 bytes from 64.233.161.104: icmp_seq=2 ttl=240 time=4449.298 ms
64 bytes from 64.233.161.104: icmp_seq=6 ttl=240 time=1692.930 ms
64 bytes from 64.233.161.104: icmp_seq=3 ttl=240 time=4730.675 ms
64 bytes from 64.233.161.104: icmp_seq=4 ttl=240 time=4203.077 ms
64 bytes from 64.233.161.104: icmp_seq=5 ttl=240 time=4004.036 ms
64 bytes from 64.233.161.104: icmp_seq=8 ttl=240 time=1236.735 ms
64 bytes from 64.233.161.104: icmp_seq=10 ttl=240 time=1667.189 ms
^C
--- www.l.google.com ping statistics ---
15 packets transmitted, 9 packets received, 40% packet loss
round-trip min/avg/max/stddev = 1031.102/2682.925/4730.675/1513.236 ms
|
From Brendan Gregg:
“seeksize.d prints the disk head seek distance by process. This can identify whether processes are accessing the disks in a “random” or “sequential” manner.”
:-O