Hi there 👋

告別密碼！使用 SSH CA 證書實現更安全、更方便的伺服器登入 您是否還在為管理多台伺服器上數不清的 authorized_keys 檔案而煩惱？或是擔心某位同仁的私鑰外洩，卻無法輕易地撤銷其存取權限？ 傳統的 SSH 公鑰認證雖然比密碼安全，但在大規模的環境中，金鑰管理本身就是一個挑戰。今天，我們要介紹一個更優雅、更安全的解決方案：SSH 憑證頒發機構 (Certificate Authority, CA)。 透過建立自己的 CA，您可以集中管理所有伺服器的信任關係。伺服器不再需要知道每一個使用者的公鑰，它只需要信任您的 CA。接著，您可以為每一位使用者簽發有時效性的短期證書，大幅提升安全性與管理便利性。 這篇文章將帶您一步步建立自己的 SSH CA，並使用它來簽發使用者證書，實現無痛、安全的伺服器登入。 核心概念與角色分工 在開始之前，讓我們先理解整個流程中的三個主要角色以及它們各自掌管的檔案。 角色 職責 相關檔案 憑證頒發機構 (CA) 簽署使用者公鑰，核發證書。是信任的根源。 ca_key (私鑰), ca_key.pub (公鑰) SSH 伺服器 (Server) 被登入的遠端主機。它不認識使用者，只信任 CA。 ca_key.pub (CA 的公鑰) SSH 客戶端 (Client) 發起連線的使用者。持有自己的私鑰和 CA 核發的證書。 id_ed25519 (私鑰), id_ed25519-cert.pub (證書) 簡單來說，Server 藉由擁有 CA 的公鑰來信任 CA。Client 藉由持有 CA 簽發的證書來向 Server 證明自己的身份。 Step 1: 建立憑證頒發機構 (CA) 位置： 在您的管理工作站或一個安全的機器上 (此處即為 CA)。 首先，我們需要產生一組專門用來當作 CA 的金鑰。這組金鑰是整個信任鏈的核心，請務必妥善保管 CA 的私鑰 (ca_key)。 ...

產生一組金鑰 ssh-keygen -t rsa -b 4096 -f ca_key -C "My SSH Certificate Authority" 會產生兩個檔案 ca_key ca_key.pub 公鑰分發到要被登錄的機器上 (sshd server) /etc/ssh/sshd_config TrustedUserCAKeys /etc/ssh/ca_key.pub systemctl restart sshd 產生一組金鑰,做為客戶端的金鑰 ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519 -C "user@example.com" 會產生兩個檔案 id_ed25519 id_ed25519.pub 用 ca 私鑰與 用戶公鑰簽發證書 ssh-keygen -s ca_key -I "user@example.com-cert" -n user1,user2 -V +52w id_ed25519.pub -s ca_key: 指定用於簽署的 CA 私鑰。 -I “user@example.com-cert”: 指定一個證書 ID，用於日誌記錄和審計。 -n user1,user2: 指定此證書允許登錄的用戶名（如果未指定，則默認為金鑰的註釋部分）。這是 SSH 伺服器在驗證證書時會檢查的用戶名。 -V +52w: 設置證書的有效期，例如這裡設置為 52 週。 ...

http { upstream ups { server 192.168.1.1 max_fails=1 fail_timeout=10s; server 192.168.1.2 max_fails=1 fail_timeout=10s; server 192.168.1.3 max_fails=1 fail_timeout=10s; keepalive 1000; } server { listen 80; server_name _; location / { proxy_next_upstream error timeout; proxy_next_upstream_tries 0; proxy_pass http://ups; } } } 配置說明 max_fails=1 fail_timeout=10s 每 10 秒計數到一次失敗，節點判定為壞點 10秒鐘 以此類推 當 max_fails=0 時，停用失敗計數器，即永遠不會判定壞點 proxy_next_upstream error timeout 那些請求狀態會被判定失敗，計算到 max_fails 的計數器 可選的項目有： error timeout invalid_header http_500 http_502 http_503 http_504 http_403 http_404 http_429 non_idempotent off proxy_next_upstream_tries 0 upstream servers 嘗試請求的次數 ...

Vscode Terminal control + p 無法切換前一個命令 常用的 terminal 工具原始設定使用 ctrl + p 熱鍵，切換到上一個命令。 但在 vsocde 裡的 terminal 會變成 quick open 如果想讓熱鍵可以是切到上一個命令可調整 Preferences > Setting > 搜尋框輸入 terminal.intergrated.commandToSkipShell > Add item -workbench.action.quickOpen

Loki 環境說明 Loki 版本 2.9.2 Loki 使用 3台 Monolithic mode 的 cluster ring kvstore 使用 memberlist Storage 在 AWS S3 情境說明 目前使用 Loki 記錄 nginx 的訪問日誌， 日誌有點份量之後，Loki 原生的統計函數變得相當吃緊，查詢請求動不動就跑到 CPU 100% 然後 timeout。 嘗試過將機器規格提升到兩台 32 core 的機器，雖然可以感覺到查詢速度有變快，但效果還是非常不理想。 沒人查詢時基本上 CPU 也是整個空閒，相當的浪費資源。 官方文件上有看到 record data 的做法。 基本上是利用 ruler 模組，定期執行統計，記錄到 prometheus 或其它支援的 storage，不用每次都跑一堆計算，可以改拉 prometheus 預算好的資料。 下圖取自 record data 後拉取的資料 (24小時有 272M筆訪問記錄，284GB) Ruler 單機的 Loki 你可以將 rule 規則存放在 Disk 中，直接編輯， 如果是 cluster 可以啟用 rule api 來管理規則，將規則存放到類似 S3 的 storage 供每個節點存取。 (下述的範例以 cluster 為原則) ...

Windows 使用 rsync 引發的權限問題 如果你在 Linux 上使用過 rsync 指令，多少需要瞭解一下檔案權限的問題。 在 Windows 上 Rsync，可以透過一些模擬 Linux API 的指令來實現 這裡用到的是 cwRsync，可以到官網下載 rsync client 純指令版 (rsync-client 是 free 的，其它有些東西可能需要付費，看自己的需求) 這裡列舉幾個我自己在 Windows 上遇到的權限問題 rsync 後的檔案或資料夾，無法開啟或刪除檔案 資料夾安全性顯示 權限排序不正確 跟 null sid 權限問題處理 1. 無法開啟或刪除資料夾 可以試著在執行 rsync 指令時加上參數 --chmod=ugo=rwX -r 來改變檔案的權限 rsync -avz --chmod=ugo=rwX -r <source> <destination> 2. 資料夾安全性顯示 權限排序不正確 跟 null sid 如果權限排序不正確，可以試著在 cwrsync/etc 底下加入 fstab 檔， 設定 noacl 來排除，具體可以參考 refer 連結，範例如下: # /etc/fstab none /cygdrive cygdrive binary,noacl,posix=0,user 0 0 ...

場景 事情是這樣的， 某天我弄了一個 windows 的 bat 檔，預計使用 rsync 將檔案同步到 windows 本地目錄。 於是搞了個腳本，類似這樣， dirpath 則以環境變數的方式代入。 cd %dirpath% rsync --delete remote local 想了想， 如果前面程序如果失敗，沒有將 dirpath 建立出來， 我這個 rsync –delete 就可怕了，於是加了一行判斷 cd 失敗就終止。 cd %dirpath% if %ERRORLEVEL% NEQ 0 exit %ERRORLEVEL% rsync --delete remote local 本機測試完後，開開心心的到其它機器去測試。 結果開始噴 rsync delete 一些奇奇怪怪的檔案。 我心裡想 cd 失敗的話， 沒有 pathdir 不是應該會退出程序嗎? 細查後 dirpath 資料夾也有正常建立， 為什麼 cd 不成功也沒有 return error code 呢? 實測 原因是我自己電腦上測試的時候都在 c 碟上面進行， 當涉及 device (c, d 碟) 切換的時候， cd 指令並不會成功。 如果路徑確實存在也不會報錯。 ...