为何在tmux/screen中keyctl读取@u用户密钥有时提示权限拒绝？

问题现象 #

在screen或tmux会话中，偶尔会随机出现无法从@u（用户密钥环）读取密钥的情况，即使是刚添加的密钥也会报错。其他终端环境下操作完全正常：

正常工作时的命令及输出 #

$ keyctl pipe $(keyctl padd user test @u <<<"test messsage")
test messsage

失败时的命令及输出 #

$ keyctl pipe $(keyctl padd user test @u <<<"test messsage")
keyctl_read_alloc: Permission denied

成因分析 #

• 密钥环与登录会话绑定：Linux用户密钥环（@u）和用户的登录会话强关联。如果screen/tmux是在旧登录会话（比如之前的SSH连接）中启动的，当原会话失效（SSH断开重连）后，系统会生成新的用户密钥环，但screen/tmux内的进程仍保留旧会话的密钥环上下文，无法访问新的密钥环资源。
• 进程上下文未同步：密钥环的访问权限依赖于进程的会话ID（SID）、控制终端等上下文信息。screen/tmux作为会话管理器，会隔离自身进程的上下文，当系统通过PAM模块（如pam_keyinit）刷新密钥环后，screen/tmux内的进程无法自动同步这个变化，导致权限校验失败。
• 随机触发的诱因：系统在某些场景下会自动刷新密钥环（比如用户重新登录、PAM会话更新），如果此时screen/tmux会话未主动同步上下文，就会随机触发权限拒绝问题。

修复与预防方案 #

• 临时修复：重新初始化会话密钥环
  在出现问题的screen/tmux会话中执行以下命令，创建新的会话密钥环并关联当前进程：

  keyctl session
  

  执行后即可正常访问@u密钥环。

• 启动时同步密钥环
  启动screen/tmux前，先将用户密钥环链接到当前会话密钥环，确保子进程能继承访问权限：

  keyctl link @u @s && screen
  

  或者直接在screen/tmux的配置文件（如~/.screenrc或~/.tmux.conf）中添加上述命令，自动完成链接。

• 配置PAM自动同步
  为screen/tmux添加PAM规则，确保每次启动时自动初始化密钥环：

  1. 创建或编辑/etc/pam.d/screen和/etc/pam.d/tmux文件
  2. 添加以下内容：

     session optional pam_keyinit.so force revoke
     

  这样每次启动screen/tmux时，PAM会强制初始化新的密钥环，与当前用户会话保持同步。

• 避免复用过期会话
  当登录会话失效（如SSH断开重连）后，尽量关闭旧的screen/tmux会话并重新启动，避免进程保留过期的密钥环上下文。

内容的提问来源于stack exchange，提问作者Sam Liddicott