HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
drduh
YubiKey-Guide
HTML2016–2026
drduh / YubiKey-Guide

YubiKey-Guide

Community guide to using YubiKey for GnuPG and SSH - protect secrets with hardware crypto.

38Distinct people
59Mentions
2Explicit recommenders
13.1KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Community guide to using YubiKey for GnuPG and SSH - protect secrets with hardware crypto.

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

I haven't tried using the GPG mode on mobile, but I've had absolutely 0 issues with it on Linux. Just followed the arch wiki setup and this random guide I found:…

vladvasiliu used a recommendation phrase. 4 indexed comments match. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.

Protecting SSH Keys with macOS Secure Enclave direct repository linkDebated

The discussion centers on the trade-offs between using macOS Secure Enclave for SSH keys versus traditional methods, with users praising the hardware-bound security but criticizing the lack of portability and backup capabilities. Strong disagreements arise regarding whether the biometric requirement is a feature or a bug for automation, and if the perceived security benefits outweigh the usability friction compared to passphrase-protected keys.

139 readable replies · Supporting reply 1 · Supporting reply 2 · Supporting reply 3 · Supporting reply 4

Mentions over time

HN mentions by year59 dated mentions

Observed mentions: 2016-02-02 12:15:55 UTC to 2026-10-30 08:31:13 UTC.

0510152016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 2 mentions; 1 submissions, 1 comments20162017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 5 mentions; 1 submissions, 4 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 13 mentions; 1 submissions, 12 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 7 mentions; 1 submissions, 6 comments20212022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 9 mentions; 1 submissions, 8 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 10 mentions; 1 submissions, 9 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 4 mentions; 1 submissions, 3 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC211
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC000
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC514
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC13112
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC404
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC716
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC918
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC1019
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC000
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC505
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC413

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
This guide demonstrates how to store credentials on a YubiKey. The private keys cannot be copied back out of the device. Keys are first generated on an offline computer, then exported to encrypted offline backups, and then transferred to YubiKey for daily use. If the YubiKey is lost, stolen, or destroyed, keys can be restored from an encrypted backup to a new device. Purchase YubiKey Prepare setup environment Download and verify Debian Create bootable USB device Prepare hardware Install software Prepare GnuPG Configuration Identity Key algorithm Expiration Passphrase Create Certify key Create Subkeys Verify keys Backup keys Export public key Configure YubiKey Change PIN Set attributes Transfer Subkeys Signature key Encryption key Authentication key Verify transfer Finish setup Using YubiKey Encryption Signature Configure touch SSH Replace agents Copy public key Import SSH keys SSH agent forwarding Use ssh-agent Use S.gpg-agent.ssh Chained forwarding GitHub GnuPG agent forwarding Legacy distributions Chained GnuPG agent forwarding Using multiple YubiKeys Email Thunderbird Mailvelope Mutt Keyserver Updating keys Renew Subkeys Rotate Subkeys Reset YubiKey Optional hardening Improving entropy Enable KDF Network considerations Notes Troubleshooting Alternative solutions Additional resources Purchase YubiKey Choose a YubiKey model that includes the OpenPGP application. YubiKey Security Key and YubiKey Bio models do not include OpenPGP support and cannot be used with this guide. Verify the YubiKey at yubico.com/genuine. Select Verify Device, touch the key when prompted, and allow the site to identify the device model. This can help detect some supply chain tampering. Have at least two USB drives or microSD cards for storing encrypted offline backups in different physical locations. Prepare setup environment Use a dedicated, hardened environment to generate the keys and backups. The following environments are ordered from least to most secure for this task: Public, shared or other computer owned by someone else Daily-use personal operating system with unrestricted network access Virtualized system with limited capabilities (using virt-manager, VirtualBox or VMware, for example) Dedicated and hardened Debian or OpenBSD installation Ephemeral Debian Live or Tails booted without primary storage attached Hardened hardware and firmware (e.g., Coreboot, Intel ME removed) Air-gapped system without network capabilities, preferably ARM-based Raspberry Pi or other architecturally diverse equivalent Network isolation and dedicated hardware generally provide stronger protection than a daily-use online system. For most people, booting Debian Live from USB on a personal computer is a practical baseline. Download and verify Debian Download the latest Debian Live image and signature files. These commands download the checksum file, its signature, and the current 64-bit XFCE Live ISO: imageUrl="https://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/" curl -sfL -O "$imageUrl/SHA512SUMS" -O "$imageUrl/SHA512SUMS.sign" curl -sfLO "$imageUrl/$(awk '/xfce\.iso$/ {print $NF}' SHA512SUMS)" Download the Debian signing public key: gpg --keyserver hkps://keyring.debian.org \ --recv DF9B9C49EAA9298432589D76DA87E80D6294BE9B If the public key cannot be received, use a different keyserver or DNS server: gpg --keyserver hkps://keyserver.ubuntu.com:443 \ --recv DF9B9C49EAA9298432589D76DA87E80D6294BE9B The Debian Live signing public key is also available for import in pubkeys: gpg --import pubkeys/debian-DA87E80D6294BE9B.asc Verify the signature: gpg --verify SHA512SUMS.sign SHA512SUMS Confirm the fingerprint matches Debian's published fingerprint: gpg: Good signature from "Debian CD signing key <debian-cd@lists.debian.org>" Verify the image hash matches the signed sums file: grep $(sha512sum debian-live-*-amd64-xfce.iso) SHA512SUMS See Verifying authenticity of Debian CDs for more information. Create bootable USB device Connect a storage device and identify the device path. This guide uses /dev/sdc throughout, but this value may differ on your system. WarningThe following dd commands erase and overwrite the selected device. Check the device path before continuing! Linux $ sudo dmesg | tail usb-storage 3-2:1.0: USB Mass Storage device detected sd 2:0:0:0: [sdc] Attached SCSI removable disk Copy the Debian image to the device: sudo dd if=debian-live-*-amd64-xfce.iso of=/dev/sdc bs=4M status=progress ; sync OpenBSD $ dmesg | tail -n2 sd2 at scsibus4 targ 1 lun 0: <TS-RDF5, SD Transcend, TS3A> SCSI4 0/direct removable serial.0000000000000 sd2: 15193MB, 512 bytes/sector, 31116288 sectors $ doas dd if=debian-live-*-amd64-xfce.iso of=/dev/rsd2c bs=4m 465+1 records in 465+1 records out 1951432704 bytes transferred in 139.125 secs (14026448 bytes/sec) Prepare hardware Shut down the computer that will be used to generate keys. Disconnect internal storage and unnecessary peripherals, such as the wireless card. Install software Boot the computer from the Debian Live USB drive. Configure networking to install the required software; see Network considerations for optional restrictions. TipIf the screen locks on Debian Live, unlock with user / live Open a terminal and install the required software. Debian/Ubuntu sudo apt update sudo apt -y upgrade sudo apt -y install \ wget gnupg2 gnupg-agent dirmngr \ cryptsetup scdaemon pcscd \ yubikey-personalization yubikey-manager OpenBSD doas pkg_add gnupg pcsc-tools macOS Download and install Homebrew and the following packages: brew install gnupg yubikey-personalization ykman pinentry-mac wget Or using MacPorts, install the following packages: sudo port install gnupg2 yubikey-manager pinentry wget NixOS Use this repository's purpose-built live ISO instead of Debian Live. Copy the resulting ISO to a USB drive, boot from it, and keep the system offline while generating keys. ref=$(git ls-remote https://github.com/drduh/Yubikey-Guide refs
Read the full README on GitHub

What Hacker News says

59 sources
That was my first thought, too — this might work as one of additional methods of logging in, but not as the only one. I have been using YubiKeys for many years now, following this guide: https://github.com/drduh/YubiKey-Guide This means I can have secure private keys for ssh and gpg (cue the crowd saying gpg is insecure without offering good modern alternatives), which I can also back up. And I can set up multiple YubiKeys, which I do. An additional advantage of this solution is that you can set your YubiKey to require a touch confirmation before performing an operation. This makes it much harder for runaway AI agents to wreak havoc on your servers: there is a physical limitation, which I really like.
In Setting Up SSH Keys on macOS with Touch ID
It has become fashionable to s*t on GnuPG. I just wish all the crypto experts doing that would point me to an alternative that is functionally equivalent. Something that will encrypt using AES-256 with a passphrase, but also using asymmetric crypto. Oh, and I want my secret keys printable if needed. And I want to store them securely on YubiKeys once generated (https://github.com/drduh/YubiKey-Guide). I want to be able to encrypt my backups to multiple recipients. And I want the same keys (stored on Yubikeys, remember?) to be usable for SSH authentication, too. And by the way, if your fancy tool is written using the latest language du jour with a runtime that changes every couple of years or so, or requires huge piles of dependencies that break if you even as much as sneeze (python, anyone?), it won't do. BTW, in case someone says "age", I
Read the rest
actually followed that advice and set it up just to be there on my systems (managed by ansible). Apart from the fact that it really slowed down my deployments, the thing broke within a year. And I didn't even use it. I just wanted to see how reliable it will be in the most minimal of ways: by having it auto-installed on my systems. If your fancy tool has less than 5 years of proven maintenance record, it won't do. Encryption is for the long term. I want to be able to read my stuff in 15-30 years. So before you go all criticizing GnuPG, please understand that there are reasons why people still use it, and are actually OK with the flaws described.
In Gpg.fail
This is a good moment to remind everyone of this excellent guide: https://github.com/drduh/YubiKey-Guide it describes how to use your YubiKeys (please always use at least two, so that you have a backup) for GnuPG keys and SSH. I've been using this setup since 2018 and it is brilliant. I know GnuPG is not in fashion these days, but thanks to this setup I have SSH logins using YubiKeys, encrypted backups using GnuPG, and 2-factor authentication for a number of sites that support Webauthn. All with backup keys, which is IMPORTANT: do not get locked into using a single device, because sooner or later you will lose that device or it will suddenly die.
In Native Secure Enclave backed SSH keys on macOS
At https://github.com/drduh/YubiKey-Guide?tab=readme-ov-file#co..., these options are not the most secure one. personal-cipher-preferences CHACHA20 AES256 AES192 personal-digest-preferences BLAKE2B SHA512 SHA384 SHA256 personal-compress-preferences Uncompressed personal-aead-preferences OCB EAX default-preference-list BLAKE2B SHA512 SHA384 SHA256 CHACHA20 AES256 AES192 Uncompressed OCB EAX cert-digest-algo BLAKE2B s2k-digest-algo BLAKE2B s2k-cipher-algo CHACHA20 s2k-count 65011712 charset utf-8 no-comments no-emit-version no-greeting keyid-format 0xlong list-options show-uid-validity verify-options show-uid-validity with-fingerprint require-cross-certification require-secmem no-symkey-cache armor use-agent throw-keyids weak-digest SHA1 RIPEMD160 MD5 disable-cipher-algo 3DES CAST5 IDEA BLOW
Read the rest
FISH TWOFISH CAMELLIA128 CAMELLIA192 CAMELLIA256 disable-pubkey-algo RSA1024 trust-model tofu+pgp keyserver hkps://keys.openpgp.org keyserver-options no-honor-keyserver-url keyserver-options include-revoked keyserver-options auto-key-retrieve force-mdc require-compliance compliance de-vs These are the most secure options (correct me if I am wrong). The only drawback you may encounter is that you need GnuPG 2.3+, and some compatibility tradeoffs.
In Native Secure Enclave backed SSH keys on macOS
This was a significant problem for me across a few consulting clients. What ended up making things significantly better for me was doing my SSH over GPG: https://opensource.com/article/19/4/gpg-subkeys-ssh This way, I can create and delete GPG subkeys all I want, export the SSH files for upload to a client's system. When it comes time to authenticate, I only ever have to unlock a single secret, which in my case is my GPG keys on my Yubikey devices: https://github.com/drduh/YubiKey-Guide
In Organizing multiple Git identities
The excellent guide by drduh should be mentioned here: https://github.com/drduh/YubiKey-Guide — I've been using this approach for years to store my OpenPGP keys on Yubikeys and use them for SSH. I don't generate my keys on devices. That lets me be flexible and keep backups, as well as use the same keys on multiple physical devices. Using a single yubikey is a bad idea, as you're bound to eventually lose it or break it. Hasn't happened to me yet in 5 years, but I expect it to happen. I wish more sites supported hardware keys instead of only TOTP tokens, or (heaven forbid, but corporate idiocy is plentiful) SMS.
In An Opinionated Yubikey Set-Up Guide

Showing the 15 most recent of 59 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.