如何在 Jitsi Meet 中啟用身份驗證和密碼保護

Jitsi Meet 有兩個獨立的安全控制措施：伺服器驗證決定誰可以建立會議，而會議室密碼則阻止不知道密碼的使用者加入會議室。它們分別解決不同的問題。在自架伺服器上，舊版的 Prosody「安全域」設定可以要求建立會議室時輸入使用者名稱和密碼，同時允許訪客加入。 Jitsi 的最新手冊已將此方法標記為新安裝的棄用方案，並建議改用基於令牌的身份驗證。現有管理員可以參考以下步驟作為相容性指南，但應圍繞受支援的令牌或身分提供者設定來規劃新的部署。

會議室密碼是會議中的獨立功能，與伺服器身份驗證配合使用仍然十分有用。在會議室啟動後設定密碼，透過私密頻道分享，並在邀請與會者之前，先使用另一個瀏覽器測試加入流程。

您需要哪種類型的保護？

目標	使用	它的作用
控制誰可以創建房間	伺服器身份驗證	建立房間時需要已驗證的 Jitsi 帳戶或代幣。根據訪客設置，其他人仍可以訪客身分加入。
保持現有房間的私密性	客房密碼	設定密碼後，加入房間的人員需要輸入密碼。此操作不會移除已在房間內的參與者。
請在主人到達前暫留客人。	大廳或等待主持人功能	增加了一個單獨的准入步驟。僅憑房間密碼無法確認身分或驗證密碼的接收者。

對於小型會議，一個唯一的會議室名稱加上會議室密碼可能就足夠了。對於需要基於帳戶建立會議室的組織，還需要設定伺服器驗證。對於新的自託管部署，在選擇實施方案之前，請先查看 Jitsi 目前的身份驗證指南和相關的令牌身份驗證設定。

如何為 Jitsi 房間設定密碼保護？

開始會議後，開啟工具列中的「安全性」或「會議選項」選單，選擇「密碼」操作，然後輸入強密碼。選單標籤和圖示可能因客戶端版本而異。如果會議已經開始，設定密碼會影響後續加入的人員；已加入的人員不會自動移除。當需要保密時，請將密碼與會議連結分開發送。

Jitsi 的常見問題中解釋說，會議室密碼會在會議結束後被移除，因此不應假定循環會議會保留密碼。每次新會議都需要重新設定密碼，並在您自己的部署環境中驗證其行為。任何收到或被轉發密碼的人都可能進入會議室，因此密碼與指定使用者存取清單不同。請參閱Jitsi 官方關於會議保護的常見問題。

伺服器身份驗證會帶來哪些變化？

在經典的「安全網域」設計中，Prosody 會使用本機帳戶對房間創建者進行身份驗證。然後，Jitsi 允許未經身份驗證的參與者透過訪客網域連接。當只有工作人員需要建立房間，而與會者無需帳戶時，這種方式非常有用。它不會要求每個參與者都登入。如果每個使用者都必須進行身份驗證，則需要停用訪客存取權限，或將其替換為您目前身份驗證設計中使用的身份和存取策略。

Jitsi 的文件已將這種較舊的安全性網域方法標記為已棄用，不適用於新安裝。只有當您了解此限制並維護相容的現有伺服器時，才可繼續操作。編輯前，請確認 Jitsi 的安裝方式，記下您的 Jitsi Meet 主機名，備份 Prosody、Jicofo 和 Web 配置文件，並保持管理員會話或控制台處於可用狀態，以防語法錯誤導致服務中斷。

如何在 Debian 或 Ubuntu 軟體包安裝中啟用傳統的安全域設定？

1. 更改 Prosody 虛擬主機

正常開啟 Jitsi 主機名稱對應的 Prosody 檔案/etc/prosody/conf.avail/jitsi.example.com.cfg.lua。將下面的範例主機名稱替換為實際網域名稱。在主虛擬主機中，將身份驗證模式變更為雜湊內部密碼。在其後新增訪客虛擬主機：

VirtualHost "jitsi.example.com"
    authentication = "internal_hashed"

VirtualHost "guest.jitsi.example.com"
    authentication = "jitsi-anonymous"
    c2s_require_encryption = false

保留其他現有選項和模組。不要為該網域建立 DNS 記錄或公共憑證guest.jitsi.example.com；在此配置中，該網域為 Jitsi 內部網域名稱。

2. 將訪客網域告知 Web 用戶端

開啟現有物件/etc/jitsi/meet/jitsi.example.com-config.js並新增內容。保留現有條目和其他條目，並仔細檢查逗號：anonymousdomainhostsdomain

hosts: {
    domain: 'jitsi.example.com',
    anonymousdomain: 'guest.jitsi.example.com'
},

3. 在 Jicofo 中啟用身份驗證

編輯/etc/jitsi/jicofo/jicofo.conf。將身份驗證設定新增至現有jicofo程式碼區塊；不要建立重複的頂級程式碼區塊：

jicofo {
  authentication {
    enabled = true
    type = XMPP
    login-url = "jitsi.example.com"
  }
}

如果文件中已存在相應jicofo部分，請將這些屬性合併到該部分。設定語法和產生的檔案可能會因軟體套件版本而異，因此在重新啟動服務之前，請將結果與您目前安裝的軟體套件手冊頁面進行比較。

4. 重新啟動服務並建立帳戶

檢查修改後，請以管理員身分重新啟動服務：

sudo systemctl restart prosody
sudo systemctl restart jicofo
sudo systemctl restart jitsi-videobridge2

在 Prosody 註冊一個房間創建者帳號。替換佔位符；切勿在正式伺服器上使用範例網域名稱或弱密碼：

sudo prosodyctl register <username> jitsi.example.com <strong-password>

每個帳戶都與 Jitsi 主機名稱關聯。如果您以後需要撤銷存取權限，請建立單獨的帳戶，而不是共用一個管理員憑證。 Jitsi 的安全性網域文件列出了特定於軟體包的設定路徑和註冊命令。文件也明確指出該方法已棄用。

Docker 中的設定有何不同？

請勿編輯執行容器內的文件，也不要將 Debian 軟體包路徑複製到 Docker 部署環境中。在官方的 Docker Compose 設定中，身份驗證是透過部署環境變數檔案來配置的。手冊中記錄了內部帳戶身份驗證的相關值：

ENABLE_AUTH=1
ENABLE_GUESTS=1
AUTH_TYPE=internal

如果與會者無需擁有個人帳號即可加入會議，請保持訪客進入權限啟用狀態。啟用訪客權限後，未經身份驗證的使用者可以根據配置的訪客行為加入會議；他們不會成為已驗證的會議室創建者。使用 Compose 工作流程套用環境更改，並檢查日誌，看看服務是否正常啟動。

請透過 Prosody 服務建立內部用戶，而不是修改產生的容器配置。官方手冊示範如何在 Prosody 容器中開啟 shell 並使用 `sudo config` 指令註冊使用者。配置路徑和 XMPP 域取決於 Compose 版本；在文件中提供的Dockerprosodyctl映像中，Prosody 配置位於 `/etc/ /config/prosody.cfg.luaprosody/ config meet.jitsi...

如何確認該保護措施有效？

打開一個隱私瀏覽窗口，嘗試建立一個新房間。按照常規設置，應該會提示輸入帳號憑證。
使用新帳號登入並建立會議室。確認會議載入成功，且主持人擁有預期的主持人權限。
使用其他瀏覽器以訪客身份加入。如果已啟用訪客功能，則無需建立者帳戶即可加入；如果需要額外的准入驗證，請新增房間密碼或大廳密碼。
設定房間密碼，然後分別嘗試從新建的私人視窗加入房間（不設定密碼和設定密碼兩種情況）。確認設定密碼後，房間內已有的參與者是否仍保持連線。
測試會議結束後，建立一個新房間，並檢查是否需要重新設定密碼，如 Jitsi 常見問題中所述。

如果始終未出現登入提示，請檢查 Prosody 主機名稱、Jicofo 區塊、用戶端anonymousdomain值和服務日誌。常見的配置錯誤是使用了與 Prosody 和主主機名稱不匹配的訪客域名config.js，或者添加了第二個 Jicofo 區塊而不是擴展現有區塊。如果訪客無法加入，請確認是否已啟用訪客存取權限，以及已設定的訪客網域是否與主主機名稱相符。

新安裝該選擇什麼？

除非出於特定的相容性原因，否則請勿使用已棄用的安全性網域設定方案啟動新的部署。 Jitsi 目前的自架文件建議在新安裝中使用令牌認證，而其更廣泛的認證指南則介紹了更新的身分提供者整合。這些方法需要額外的頒發者、簽名或身分提供者配置；它們不能與 Prosody 會議室密碼互換。請選擇符合您需求的模型，然後在適當情況下使用會議室密碼或大廳作為單獨的會議層級控制措施。

簡而言之：使用帳號或令牌認證來控制誰可以建立房間，並設定房間密碼以限制只有知道密碼的人才能加入。請分別測試這兩種方法，因為啟用其中一種並不會自動啟用另一種。