私钥文件权限必须是600。OpenSSH客户端会因权限宽松（如644、755）直接拒绝加载并报错，因私钥泄露等同密码泄露；~/.ssh目录权限须设为700，且不可用sudo chmod以免归属变更。
私钥文件权限必须是600吗
必须。OpenSSH 客户端在读取私钥时会主动检查文件权限，如果 id_rsa 或其他私钥文件权限宽松（比如 644、755），会直接拒绝加载并报错：Permissions for 'id_rsa' are too open。这不是警告，是硬性拦截。
原因很简单：私钥一旦被同服务器上其他用户或进程读取，等同于密码泄露。Linux 文件系统层面的权限是最基础、最有效的第一道防线。
- 用
chmod 600 ~/.ssh/id_rsa修正权限（注意不是chmod 600 id_rsa，路径要完整） -
~/.ssh目录本身也得收紧：chmod 700 ~/.ssh，否则目录可遍历可能暴露known_hosts或其他敏感文件 - 别用
sudo chmod修权限——改完归属可能变成 root，导致你自己的用户无法读取
用 ssh-agent 管理私钥比直接放磁盘安全在哪
本质区别在于：磁盘上的私钥是静态明文（哪怕加密了，解密口令常被缓存），而 ssh-agent 中的私钥是内存驻留、带访问控制的解密后密钥句柄，不落地、不跨会话继承、可按需限制使用次数和目标主机。
典型风险场景：笔记本休眠后被他人物理接触；CI/CD 机器上脚本意外打印 $HOME/.ssh/id_rsa 路径；运维同事临时借用终端执行命令。
- 启动代理：
eval $(ssh-agent -s)，然后用ssh-add ~/.ssh/id_rsa加载（支持-t 3600设超时） - 避免无口令私钥：用
ssh-keygen -p -f ~/.ssh/id_rsa给已有私钥加口令，再交给ssh-agent缓存一次 -
ssh-add -l查看已加载密钥，ssh-add -D清空——别依赖“关终端就自动清”，有些终端复用会话不会触发退出钩子
Git SSH 连接失败但提示 “Could not open a connection to your authentication agent” 怎么办
这不是 Git 的问题，是 ssh-agent 没跑起来，或者当前 shell 没继承它的环境变量（主要是 SSH_AUTH_SOCK）。Git 调用 ssh 时发现没代理可用，就退化成直读磁盘私钥——这时如果权限不对，就卡在上一个错误；如果权限对但没代理，它其实能连，但失去所有代理带来的保护能力。
- 先确认代理进程存在：
pgrep -u $USER ssh-agent，没有就重跑eval $(ssh-agent -s) - 检查变量：
echo $SSH_AUTH_SOCK，为空说明当前 shell 不知道代理在哪，常见于 tmux/screen 新窗口、IDE 内置终端、某些桌面环境启动的终端 - VS Code 用户：在设置里开
terminal.integrated.env.linux，手动注入SSH_AUTH_SOCK变量值（查当前终端的$SSH_AUTH_SOCK后填进去）
把私钥放进 Docker 容器或 Kubernetes Secret 就安全了吗
不安全。容器镜像层、构建缓存、运行时挂载点、Pod 日志、etcd 存储都可能让私钥意外暴露。Kubernetes Secret 只是 base64 编码，不是加密，且默认以文件形式挂载进容器，权限控制弱于宿主机 ~/.ssh。
真正该做的是：剥离私钥依赖，用更可控的身份机制替代。
- CI/CD 场景优先用 deploy key（GitHub/GitLab 提供的只读/只写仓库级密钥），限制作用域
- K8s 内服务间调用别走 SSH，改用 ServiceAccount Token + RBAC，或 SPIFFE/SPIRE 做身份断言
- 真要进容器：用
tmpfs挂载 Secret，并在容器启动脚本里chmod 600 /run/secrets/id_rsa，启动后立即ssh-add并unset SSH_AUTH_SOCK防泄漏
