Last week, a backdoor was discovered in xz-utils. The backdoor processes commands sent using RSA public keys as a covert channel. In order to prevent anyone else from using the backdoor, the threat actor implemented a cryptographic signature check on the payload.

I have seen a number of people claim that this would necessarily result in an obviously invalid RSA public key, or at least one with no corresponding private key.

This is incorrect, and someone nerd sniped me into proving it.

GitHub’s implementation of git over ssh identifies accounts (for purposes of access control) solely by ssh public key. As a consequence, a particular public key can be associated with, at most, one account. Deploy keys are even more restricted - they can only be associated with a single repository. While ssh can try several keys, GitHub doesn’t know what you’re trying to access until after you authenticate, so a workaround is required to select the right key.

There a few systems that I frequently work on from multiple locations. I like to be able to log back in and pick up where I left off after disconnecting and screen is great for that, but I have to remember to start it before I do anything else. After forgetting one too many times, I figured out how to start it automatically when I open an interactive SSH session. Here’s what I came up with: