GitHub CLI Linux 金鑰到期怎麼辦？重新載入 APT／RPM keyring

先判斷你的 gh 是否受影響#

如果錯誤訊息包含 EXPKEYSIG、NO_PUBKEY、repository is not signed 或 metadata signature verification failed，優先處理 keyring 與 repository 指向，不要先關閉 APT／DNF 的簽章驗證。

先確認系統目前信任哪把 key#

官方新 keyring 應同時包含舊、新兩個 fingerprint。可以先在 Debian／Ubuntu 檢查常見路徑：

1
gpg --show-keys --with-fingerprint /etc/apt/keyrings/githubcli-archive-keyring.gpg
2
gpg --show-keys --with-fingerprint /usr/share/keyrings/githubcli-archive-keyring.gpg
3
sed -n '1,80p' /etc/apt/sources.list.d/github-cli.list

實際存在的 keyring 路徑依安裝方式而異；不要因為第一個路徑不存在就建立第二份相似檔案。檢查 github-cli.list 裡的 signed-by，讓它和你驗證過的 keyring 路徑一致。

這次輪替應看到的 fingerprint 是：

• 舊 key：2C6106201985B60E6C7AC87323F3D4EA75716059。
• 新 key：7F38BBB59D064DBCB3D84D725612B36462313325。

兩把都出現，代表 keyring 已能覆蓋輪替期間的套件；只看到舊 key，或 fingerprint 不在官方文件列出的值中，就應重新下載官方 keyring。不要把任意 keyserver 回傳的 key 視為可信來源。

RPM 系統可以先列出套件資料庫裡標示為 GitHub CLI 的公鑰：

1
for key in $(rpm -qa gpg-pubkey); do
2
  rpm -qi "$key" | grep -q '[email protected]' && rpm -qi "$key"
3
done

確認 Packager 是 GitHub CLI 的官方識別後，再檢查是否同時有新、舊 fingerprint。不要在還沒核對 fingerprint 和 Packager 前刪除 gpg-pubkey；刪錯可能影響同一台主機上的其他 repository。

Debian／Ubuntu：重新下載官方 keyring#

如果 APT keyring 只有舊 key，使用 GitHub CLI 官方提供的 keyring URL 覆寫該 repository 實際使用的檔案：

1
sudo mkdir -p -m 755 /etc/apt/keyrings
2
sudo curl -fsSL -o /etc/apt/keyrings/githubcli-archive-keyring.gpg \
3
  https://cli.github.com/packages/githubcli-archive-keyring.gpg
4
sudo chmod go+r /etc/apt/keyrings/githubcli-archive-keyring.gpg
5
sudo apt update
6
sudo apt install gh

如果 github-cli.list 的 signed-by 指向 /usr/share/keyrings，就把下載目標改成那個既有路徑，或同步修正 source list 後再執行 apt update。修正後重新執行 gpg —show-keys —with-fingerprint，確認 fingerprint，而不是只看 apt update 沒有紅字。

Dockerfile 也要在 apt-get update 之前載入新 keyring，否則本機修好但 CI build 仍會失敗：

1
RUN mkdir -p -m 755 /etc/apt/keyrings \
2
    && curl -fsSL -o /etc/apt/keyrings/githubcli-archive-keyring.gpg \
3
       https://cli.github.com/packages/githubcli-archive-keyring.gpg \
4
    && chmod go+r /etc/apt/keyrings/githubcli-archive-keyring.gpg

若某個 image 根本不需要 gh，移除不用的 GitHub CLI repository 也是合理做法；不要用 allow-unauthenticated 或關閉 repository signature 來繞過錯誤。

Fedora、RHEL、CentOS：重新載入 RPM repository#

RPM 系統的做法是重新取得官方 repo file，讓新的 gpgkey 設定寫入 repository。依系統使用的工具選一組：

1
# DNF5
2
sudo dnf config-manager addrepo --overwrite \
3
  --from-repofile=https://cli.github.com/packages/rpm/gh-cli.repo
4
sudo dnf update gh
5

6
# DNF4
7
sudo dnf config-manager --add-repo https://cli.github.com/packages/rpm/gh-cli.repo
8
sudo dnf update gh
9

10
# yum
11
sudo yum-config-manager --add-repo https://cli.github.com/packages/rpm/gh-cli.repo
12
sudo yum update gh

如果使用 zypper，先移除現有的 gh-cli repository，再以官方 repo URL 重新加入後更新：

1
sudo zypper removerepo gh-cli
2
sudo zypper addrepo https://cli.github.com/packages/rpm/gh-cli.repo gh-cli
3
sudo zypper refresh
4
sudo zypper update gh

系統可能提示匯入新的 signing key。先比對 fingerprint 與 Packager，再接受；如果更新後仍失敗，才回頭用 rpm -qa gpg-pubkey 找出仍被信任的舊 key，確認它確實屬於 GitHub CLI 後再依官方說明移除並重裝。

重新更新後如何驗證#

套件更新完成後，至少在同一台主機上做三層確認：

1
gh --version
2
apt-cache policy gh
3
dnf info gh

Debian／Ubuntu 只需執行 apt-cache，RPM 系統只需執行 dnf info。你應看到套件可以從預期的官方來源解析，apt update 或 dnf refresh 不再出現 EXPKEYSIG、NO_PUBKEY 或 unsigned repository；CI image 則要重新 build 一次，確認沒有沿用舊 layer。

若 gh 是由 runner image、cloud-init 或 Ansible 安裝，請把新的 keyring 載入步驟放回 provisioning code，並讓主機重建一次。只在現有 VM 手動修好，下一批 autoscaling runner 仍可能帶著過期 key。

這次不要採用的解法#

• 不要用 apt 的 allow-unauthenticated、跳過 GPG check 或 DNF 的弱化驗證旗標。
• 不要從不明 keyserver 匯入看似相近的 GitHub key。
• 不要為了避開 repository 錯誤，改裝未驗證來源的 community gh package。
• 不要在沒有確認 Packager 與 fingerprint 前刪除所有 gpg-pubkey。
• 不要只修本機；把 keyring、source list 和 Docker／runner provisioning 一起納入版本控制與重建測試。

結論：更新 keyring，不要繞過簽章#

這次 GitHub CLI Linux 金鑰輪替的核心是讓官方 APT／RPM repository 重新信任正確 key。先辨識安裝來源，再檢查舊、新 fingerprint；確認 signed-by 或 repo file 指向官方 keyring，最後用 package manager 與 CI image 做一次完整更新。這樣才能同時修復開發機、self-hosted runner 和 Docker build，而不會把安全驗證變成被繞過的設定。

這類 Linux 套件問題和 GitHub Codespaces port forwarding 的安全設定 一樣，重點不是讓指令「先跑起來」，而是確認信任邊界仍指向可驗證的官方來源。

常見問題#