Swipe to SSH

SSH (Yubi)Key Authentication

SSH with private keys coming from secure hardware. What's not to like?

You've read the How-To. You've changed the pin with:

yubico-piv-tool -a change-pin

You're generating a resident key with:

ssh-keygen -t ed25519-sk -O resident -f ~/.ssh/yubi_ed255_key

After entering your pin, the above command breaks with "enrollment failed: invalid format". Surely you're doing something wrong? After a minute of head scratching, you try again, this time with:

ssh-keygen -vv -t ed25519-sk -O resident -f ~/.ssh/yubi_ed255_key

And are greeted with a confusing error. According to the error code (FIDO_ERR_PIN_NOT_SET) the resident key can not be generated because your YubiKey is not protected with a pin. But you've changed it already - what gives?

You've changed the PIN for the PIV application... which is different from the FIDO2 application.

Right idea, right PIN, wrong application?

Turns out you're missing the right tool. Get the correct one with:

${SUDO} apt install yubikey-manager

And then configure the FIDO2 application code with:

ykman fido set-pin

Now you can rerun the command from above and generate a private key directly with the YubiKey.

Things that work

The private key file, generated by the ssh-keygen command, can be nuked. It is after all a resident key, accessible directly from the YubiKey device. And you probably didn't add a keyphrase for it either.

So you can now load the private key into SSH agent, with:

ssh-add -K

You'll need to type in the PIN you set earlier.

... and a few that don't

The main problem with the above setup is that every use of the private key, even when loaded to the agent, requires to touch the magic button. To make things worse, the client doesn't show any hint what is needed, from a casual observer's point of view establishing the connection seems to hang.

This is okay for random logins, but breaks non-interactive workflows, and utterly messes up remote autocomplete. Touch the key one time too few, and the autocomplete never finishes. Touch it one time too many, and you've just vomited an OTP string to your terminal.

An ideal setup would allow the agent to authenticate without interaction for a configurable time, but so far this seems not to be supported.

Near-future experimentation

Documentation for ssh-keygen states that the resident key may be generated with the additional option -O no-touch-required to allow fully non-interactive use. At least at the time of writing, portable OpenSSH v8.4 does not appear to support the option, which may be for the best. Additionally, the public key requires special annotation for its entry in authorised_keys but even then it's not a good idea.

Because this option essentially would turn the YubiKey into a USB-attached SSH trust/identity dongle, it's far too dangerous to be used without other mitigations.

The missing hint

The bit about FIDO2 application for SSH client and the necessary command was found here.

Helpful two-liners

When changing the PIN/PUK codes, of course you want the new codes to be random. A really easy way to generate them is with python. Like this:

% python3

import secrets

secrets.randbelow(10**6) # for PIN

secrets.randbelow(10**8) # for PUK

Getting home for plague'mas

Be honest

Planning to travel to visit your family in these plague-ridden times, you're really saying:

"I miss my family so much they will see me if it's the last thing they do."

It's that time of the year again

Page from an undated journal

Daddy's crying. Mommy has a black eye. Little sister's hiding under her bed.

Yep, it's christmas.

Perception is almost everything

Misunderstood Indexing

Holding the number-one spot on Corruption Perceptions Index tells nothing about how well a country is doing.

It merely highlights how bad the situation is even for the runner-up.

Dear online surveillance addicts

Ground rules for acceptable ads online

The following is an edit of a piece originally written in November 2015.

The pinnacle of non-intrusive online ads were the original Google search ads. They were out of the way, clearly marked as ads - and hence could be visually filtered out. They were pure text, so could be neatly included as elements on the rendered page. And they were always targeting an INTEREST. Not an individual.

I will take that as the minimum acceptable advertising behaviour. I'm not implying it's perfect, but at least we set a clear set of ground rules. With that in mind, my ideal, non-intrusive ads mechanism builds on the following rules:

  • Ads must never be inline to page content.
  • Even when clearly out of the way, ads must not be allowed to mimic page content; they must be clearly marked as ads.
  • Text only.
  • I might accept an image within the ad, provided it was always served from the content provider's system.
  • As an extension to previous point: if the served image size would exceed a notable fraction of the page size, it must not be included in the output.
  • No user tracking of any kind.
  • No third-party javascript. Ever.
  • At most 15% of display real estate allowed to be used by ads. Including the padding in the UI. (It all counts as space denied from content.)
  • Not allowed to affect page content load times. Ad material must be included at the end of the page code. If your service pushes ads from internal and separate system, hard timeouts must be imposed: if the internal system cannot serve an ad within an allotted time, the frontend must never be forced to wait. You just missed an ad impression. Tough.
  • If clicking an ad takes a user through a bounce page, all identifiable information from the user must be stripped. Bounce page or redirect must not impose any further page loading delay.
  • No beacons.

Breaking even one of the rules automatically disqualifies you.

If you, as an advertiser, find these rules unacceptable - well, then we are in mutual disagreement. I find your ads equally unacceptable and will treat them as a form of cancer.

However, as a genuine service to the user... please allow the users to search for ads that have been displayed to them. Preferably by display context. I would be glad to return to a subject at a later date and search for something I remember seeing earlier.

The above set of rules is still not ideal, but everything that behaved according to them would at least be palatable.

Waste not, want not

Visions of future past

In our lifetime we will have seen the Western countries not just close but to barricade their borders. Should an unannounced ship approach, carrying desperate human beings fleeing the wars and the devastation, we won't be even allowed to think about accepting them.

The ships will be, not stopped and turned around, but torpedoed and sunk on sight. The drowned will be harvested for feed and fertiliser.

My only consolation is that I am old enough to not necessarily witness all of it.

So many edges

Random musings, part [REDACTED]

Software is like a diamond ...

... the better it glistens, the more edges there are.

... the toughest substance on planet, yet can shatter from a single impact.

... creating one can destroy your tools.

... no matter how well it wears, it'll still burn.

Your passwords have been compromised

Another blog post at $dayjob

So I wrote another one at work. After explaining to various parties how and why password cracking attempts happen, I felt it was prudent to write the whole thing down for future reference outside the corporate walls.

With that in mind, your passwords have almost certainly been compromised

TL;DR: use high-entropy passwords, a password manager, and proper 2-Factor authentication.

Presentation slides - Intended Consequences

DC4420 Presentation: Intended Consequences

Faithful to habits, I found myself with a presentation at dc4420. Lessons of usability and search for sanity gave rise to a talk on how deal with conflicting auditing demands.

The talk was geared towards industry long-timers who have, for reasons only marginally in their control, found themselves appeasing externalities and ticking boxes. I wanted to highlight that hope is not lost.

You can find the slides here: Intended Consequences

Evolution of debugging prowess

Evolution and progression of debugging prowess

When things break in mysterious ways, developers tend to go through a familiar series of increasingly demanding steps. As experience, skills and even personal networks grow, we can find ourselves diving ever further in the following chain:

  1. "It must be in my code." -- hours of debugging
  2. "Okay, it must be somewhere in our codebase." -- days of intense debugging and code spelunking
  3. "It HAS TO be in the third party libraries" -- days of issue tracker excavations and never-before-enabled profiling runs
  4. "It can't possibly be in stdlib..." -- more of the same, but now profiling the core runtime libraries
  5. "Please let this not be a compiler bug" -- we become intensely familiar with mailing list archives
  6. "I will not debug drivers. I will not debug drivers. I will not debug drivers."
  7. "I don't even know anyone who could help me figure out the kernel innards."
  8. "NOBODY understands filesystems!"
  9. "What do you mean 'firmware edge case'?"
  10. "Where is my chip lab grade oscilloscope?"

How far have you found yourself?