Michael Vorburger.ch Blog

Securities

2025

SSH with private keys sealed in TPM on Fedora Linux

June 19, 2025

SSH with private keys sealed in TPM on Fedora Linux

Instead of safely storing SSH private keys on a Yubikey (if you don’t have one) you might want to keep private keys sealed in TPM.

Here is how to do this on Fedora Linux using https://github.com/Foxboron/ssh-tpm-agent:

$ sudo dnf install openssl-devel
$ go install github.com/foxboron/ssh-tpm-agent/cmd/...@latest

$ ~/go/bin/ssh-tpm-keygen --supported
ecdsa bit lengths: 256 384
rsa bit lengths: 2048

As this TPM supports ECDSA keys with 384 (but not 521) bits, so:

security

2024

Visual Studio Code Tunnel systemd service authorization token refresh

February 20, 2024

Visual Studio Code Tunnel systemd service authorization token refresh

If VSC shows you:

An unexpected error occurred that requires a reload of this page. The workbench failed to connect to the server (Error: The VS Code gateway is not currently running.)

and a web page reload doesn’t help, and if code tunnel service log (or systemctl --user status code-tunnel.service, which is ~same, under Linux) shows:

● code-tunnel.service - Visual Studio Code Tunnel
     Loaded: loaded (/home/vorburger/.config/systemd/user/code-tunnel.service; enabled; preset: disabled)
    Drop-In: /usr/lib/systemd/user/service.d
             └─10-timeout-abort.conf
     Active: active (running) since Tue 2024-02-20 20:35:36 CET; 7min ago
   Main PID: 439302 (code-cli)
      Tasks: 13 (limit: 76604)
     Memory: 3.0M
        CPU: 63ms
     CGroup: /user.slice/user-1000.slice/user@1000.service/app.slice/code-tunnel.service
             └─439302 /home/vorburger/.local/bin/code-cli --verbose --cli-data-dir /home/vorburger/.vscode/cli tunnel service internal-run
Feb 20 20:41:47 HOSTNAME code-cli[439302]: [2024-02-20 20:41:47] trace refresh poll failed, retrying: Error getting authorization: authorization_pending The authorization request is still pending.
Feb 20 20:41:57 HOSTNAME code-cli[439302]: [2024-02-20 20:41:57] trace refresh poll failed, retrying: Error getting authorization: authorization_pending The authorization request is still pending.
Feb 20 20:42:07 HOSTNAME code-cli[439302]: [2024-02-20 20:42:07] trace refresh poll failed, retrying: Error getting authorization: authorization_pending The authorization request is still pending.
Feb 20 20:42:18 HOSTNAME code-cli[439302]: [2024-02-20 20:42:18] trace refresh poll failed, retrying: Error getting authorization: authorization_pending The authorization request is still pending.
Feb 20 20:42:28 HOSTNAME code-cli[439302]: [2024-02-20 20:42:28] trace refresh poll failed, retrying: Error getting authorization: authorization_pending The authorization request is still pending.
Feb 20 20:42:38 HOSTNAME code-cli[439302]: [2024-02-20 20:42:38] trace refresh poll failed, retrying: Error getting authorization: authorization_pending The authorization request is still pending.
Feb 20 20:42:48 HOSTNAME code-cli[439302]: [2024-02-20 20:42:48] trace refresh poll failed, retrying: Error getting authorization: authorization_pending The authorization request is still pending.
Feb 20 20:42:58 HOSTNAME code-cli[439302]: [2024-02-20 20:42:58] trace refresh poll failed, retrying: Error getting authorization: authorization_pending The authorization request is still pending.
Feb 20 20:43:08 HOSTNAME code-cli[439302]: [2024-02-20 20:43:08] trace refresh poll failed, retrying: Error getting authorization: authorization_pending The authorization request is still pending.
Feb 20 20:43:19 HOSTNAME code-cli[439302]: [2024-02-20 20:43:19] trace refresh poll failed, retrying: Error getting authorization: authorization_pending The authorization request is still pending.

then this means that the authentication token which the tunnel uses does not work (anymore, expired, or some GitHub security limitation; with VSC not renewing it), note this:

security

GPG hangs on hostname change

January 4, 2024

GPG hangs on hostname change

I currently use GnuPG with Yubikeys, mostly (but not only) for pass.

One fine day I’ll switch to age (from FiloSottile; with SK and TPM) with passage, and other awesome stuff; but today it’s gpg.

Today that gpg (GnuPG) 2.4.3 suddenly stopped working, just stuck and hanging in there… I’ve debugged it with strace:

$ strace gpg --debug-all --card-status
(...)
openat(AT_FDCWD, "/etc/localtime", O_RDONLY|O_CLOEXEC) = 4
newfstatat(4, "", {st_mode=S_IFREG|0644, st_size=1909, ...}, AT_EMPTY_PATH) = 0
newfstatat(4, "", {st_mode=S_IFREG|0644, st_size=1909, ...}, AT_EMPTY_PATH) = 0
read(4, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\5\0\0\0\5\0\0\0\0"..., 4096) = 1909
lseek(4, -1217, SEEK_CUR)               = 692
read(4, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\6\0\0\0\6\0\0\0\0"..., 4096) = 1217
close(4)                                = 0
newfstatat(AT_FDCWD, "/run/user/1000/gnupg/S.keyboxd", {st_mode=S_IFSOCK|0700, st_size=0, ...}, 0) = 0
socket(AF_UNIX, SOCK_STREAM, 0)         = 4
newfstatat(AT_FDCWD, "/run/user/1000/gnupg/S.keyboxd", {st_mode=S_IFSOCK|0700, st_size=0, ...}, 0) = 0
connect(4, {sa_family=AF_UNIX, sun_path="/run/user/1000/gnupg/S.keyboxd"}, 32) = 0
recvmsg(4,

Turns out this is https://dev.gnupg.org/T6838, which I found after some research, via https://bugzilla.redhat.com/show_bug.cgi?id=2249218.

security

2021

[Krypton](https://krypt.co)

May 2, 2021

Krypton

See https://krypt.co and sources on https://github.com/kryptco.

https://krypt.co/start/ => https://krypt.co/ext/ for U2F Browser Extension, if interested.

More on https://krypt.co/docs.

Setup SSH

Install the Android App, and in its Settings (Krypton Core) enable [X] Developer Mode (and review other Settings; perhaps Disable Google Analytics). Now on workstation/desktop host:

curl https://krypt.co/kr | sh

kr pair

and scan the displayed QR code in the PAIR tab on the App. The printed SSH public key is ~/.ssh/id_krypton.pub (also kr me), and can be put e.g. on https://github.com/settings/keys or on a server (also using kr add <user>@<server>) as per https://krypt.co/docs/start/upload-your-ssh-publickey.html.

security

SSH Key type `ed25519-sk` (and `ecdsa-sk`)

May 1, 2021

SSH Key type ed25519-sk (and ecdsa-sk)

Today I noticed by coincidence that (recent versions of; e.g. the one available on Fedora Silverblue 34) ssh-keygen have ed25519-sk (and ecdsa-sk) key types (-t).

Never having seen these before, I wondered what they were for…

It is explained e.g. on https://security.stackexchange.com/questions/240991/what-is-the-sk-ending-for-ssh-key-types, and in the chapter “FIDO/U2F Support” on https://www.openssh.com/txt/release-8.2.

This is very nice, as it much simplifies the much too complicated old ways of using gpg-agent to SSH with a YubiKey.

security