CentOS7中Python subprocess调用ssh-agent脚本做服务失败的解决办法

这个问题的核心原因是systemd系统服务运行在独立的无会话环境中，默认无法获取用户会话里ssh-agent的环境变量。ssh-add -l命令需要依赖SSH_AUTH_SOCK环境变量来连接到正在运行的ssh-agent进程，而系统服务默认没有这个变量，所以执行失败返回非零状态码2（这个返回码表示无法连接到ssh-agent）。

下面是几种针对性的解决方案：

方案1：让系统服务继承用户的ssh-agent环境 #

如果你的脚本需要访问root用户会话中已经启动的ssh-agent，可以按以下步骤操作：

1. 先在root终端里查看当前SSH_AUTH_SOCK的路径：

   echo $SSH_AUTH_SOCK
   

   通常root用户的这个路径是/run/user/0/ssh-agent.sock（0是root的UID）。
2. 修改你的list_keys.service配置文件，在[Service]段添加环境变量声明：

   [Service]
   Type=simple
   ExecStart=/usr/bin/python /root/list_keys.py
   StandardInput=tty-force
   Environment="SSH_AUTH_SOCK=/run/user/0/ssh-agent.sock"  # 替换为你实际查到的路径
   

3. 重新加载systemd配置并重启服务：

   systemctl daemon-reload
   systemctl restart list_keys.service
   

方案2：让服务自行启动临时ssh-agent #

如果不需要依赖用户会话中的agent，可以让脚本自己启动一个临时的ssh-agent实例，修改list_keys.sh脚本如下：

#!/bin/bash
# 启动临时ssh-agent并导出环境变量
eval $(ssh-agent -s)
# 可选：如果需要加载特定密钥，添加这一行（替换为你的密钥路径）
# ssh-add /root/.ssh/my_key
# 列出密钥
ssh-add -l
# 关闭临时agent
ssh-agent -k

这种方式不需要依赖外部的agent进程，服务会独立完成密钥列表的查询。

方案3：改用用户级systemd服务 #

如果你的脚本不需要以系统服务的高权限运行，可以将其改为用户级服务，这样会自动继承用户会话的环境变量：

1. 在root用户的配置目录下创建服务文件~/.config/systemd/user/list_keys.service：

   [Unit]
   Description=List Keys Service
   After=graphical.target
   
   [Service]
   Type=simple
   ExecStart=/usr/bin/python /root/list_keys.py
   
   [Install]
   WantedBy=graphical.target
   

2. 启用并启动用户服务：

   systemctl --user enable --now list_keys.service
   

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