终端提示 Permission denied (publickey)，但你不确定该查 iPad 还是远程 Mac？
最快处理：先确认 Git 命令实际在哪台设备运行，再检查那台设备上的 SSH 凭据。不要为了省事把私钥复制到 iPad、临时电脑或无法确认清理方式的共享主机；若远程 Mac 的密钥保管与撤销边界不清楚，先暂停使用个人凭据。
适合旅途中用远程 Mac 开发、遇到 GitHub SSH 认证失败的独立开发者。
也适合在 iPad、轻薄本与远程 Mac 之间切换工作的数字游民，以及使用临时环境的远程顾问。
里程碑一：先锁定 Git 命令所在设备
远程桌面只是屏幕与输入的通道，不会自动把 iPad 上的 SSH 密钥变成远程 Mac 的密钥。你在远程 Mac 的终端里输入 git pull，发起认证的是远程 Mac 上的 Git 和 SSH 客户端；如果你在随身设备的本地终端运行命令，凭据检查对象则是随身设备。
先在发生故障的那个终端里运行：
hostname
whoami
pwd
git remote -v
hostname 和 whoami 帮你确认当前终端连接到哪台主机、使用哪个用户；git remote -v 显示仓库的远端地址。检查远端是否是预期仓库，以及地址采用 SSH 形式（通常以 git@github.com: 开头）还是 HTTPS 形式。不要只根据屏幕上打开的是哪台设备来判断命令位置。
GitHub 的 SSH 认证依赖执行端持有的私钥，账号中登记的是对应公钥。你可以先读GitHub 关于 SSH 认证方式的说明，避免把远程 Mac 的登录凭据、iPad 的本地密钥和 GitHub 仓库认证混为一谈。
里程碑二：根据症状区分密钥、账号与权限
不要一看到 Git 操作失败，就先改网络或重新生成密钥。先在发生故障的同一终端运行 GitHub 官方连接测试：
ssh -T git@github.com
测试的关键不是能否打开 GitHub 网页，而是返回结果是否识别出你预期的 GitHub 账号。官方说明，成功认证后会显示账号名，并提示 GitHub 不提供 shell 访问；这并不等同于已经获得某个仓库的读取或写入权限。可对照测试 SSH 连接的官方步骤。
| 可观察到的症状 | 优先检查 | 下一步 |
|---|---|---|
| 连接超时、无法建立连接 | 当前网络、SSH 端口是否被拦截 | 换到可信网络复测；若网络限制 SSH，查看官方提供的其他连接方式 |
Permission denied (publickey) |
执行端选中的密钥、公钥是否登记 | 检查密钥路径和 ssh-agent，再核对 GitHub 账号 |
| 测试识别了账号，但仓库操作失败 | 远端地址、仓库是否存在、账号是否有权限 | 确认组织授权及所需读写权限 |
| 测试识别了错误账号 | 当前终端加载了哪把密钥 | 检查 SSH 配置和 agent，避免不同账号的密钥串用 |
这些错误指向不同层级。GitHub 将 Permission denied (publickey) 归为 SSH 认证问题；仓库不存在或账号没有访问权，也可能呈现为仓库访问失败。可按SSH 故障排查文档对照具体错误，再查看仓库克隆错误与权限检查说明。
⚠️ 如果网络不允许常规 SSH 连接，先确认故障是连接建立失败，而不是账号或仓库权限错误。不要为了“试试看”就把私钥转发到另一台设备；GitHub 的排障文档也列出了防火墙限制下的连接替代路径。
里程碑三：在可信执行端检查 GitHub SSH 密钥
确认命令运行在远程 Mac 后，再在该主机上检查已有密钥。以下命令只列出 .ssh 目录中的文件名，不会显示私钥内容：
ls -la ~/.ssh
ssh-add -l
通常，同名的 .pub 文件是公钥；不带 .pub 后缀的配对文件可能是私钥。不要把私钥内容粘贴进聊天、工单、网页或文章，也不要为了排障运行会输出私钥正文的命令。若找不到适用密钥，先确认是否已有其他凭据或团队规定，再决定是否为该环境创建专用密钥；不要直接覆盖现有密钥。
ssh-add -l 用于查看当前 agent 已加载的身份。若列表为空或没有预期身份，检查 ~/.ssh/config 中 GitHub 主机条目是否指向正确的 IdentityFile，并在确认密钥文件属于当前用户后，再按官方密钥检查步骤和生成密钥及添加到 ssh-agent 的说明处理。
需要新建密钥时，先选定密钥存放位置、持有人和撤销办法；确认后再生成，避免把新旧凭据混在一起。把对应公钥登记到正确账号，并确认组织是否要求额外授权。GitHub 的添加新 SSH 密钥说明明确区分了公钥登记与执行端私钥的使用。
里程碑四：处理反复出现的口令提示
密钥口令用于保护私钥；GitHub 账号认证和远程 Mac 的用户登录是另外两类凭据。系统反复询问口令，不一定表示 GitHub 不认识这把密钥，也不表示你应该移除密钥口令。
如果 ssh-add -l 看不到预期身份，先确认当前 shell 使用的 agent 是否可用、SSH 配置是否指向正确密钥，以及重连后是否切换了主机或用户。macOS 上，GitHub 文档说明可以结合 ssh-agent 与钥匙串管理密钥口令；具体配置应以官方 agent 与钥匙串操作说明为准。钥匙串保存口令不等于取消私钥保护，也不代表每次断开远程会话后状态必然保留。
Apple 的 Remote Login 功能说明的是如何通过 SSH 或 SFTP 访问 Mac，并不证明某台远程主机的密钥隔离或会话状态。你可以查看Apple 关于 Mac 远程登录的说明，但仍需单独确认实际主机的用户权限和凭据管理方式。
里程碑五：按密钥所在位置设定风险边界
SSH agent 转发会改变认证请求的处理路径，但不应被当作“私钥从未接触风险”的保证。相较于复制私钥，优先在可信执行端管理专用凭据；如果组织政策规定使用其他认证方式，就按其要求执行。
| 密钥实际位置 | 适用判断 | 你要确认的事项 |
|---|---|---|
| 自己控制的远程 Mac 用户目录 | 可在验证主机信任边界后考虑 | 谁能访问该用户、密钥如何保管、如何移除 |
| 自己的旅行设备 | 仅当 Git 命令实际在该设备运行时才相关 | 设备是否受你控制，丢失后如何撤销 |
| 借用电脑或共享临时主机 | 不宜直接放入个人长期私钥 | 退出后能否清理文件、agent 与缓存；无法确认就改用合规替代方式或暂停 |
旅途中如果设备丢失、主机被多人使用，或你无法确认私钥是否被复制，应尽快在 GitHub 账号设置中删除对应公钥，并按组织规则撤销相关授权。删除 GitHub 上的公钥后，原私钥不能再以这条账号公钥关系完成认证；之后要为新凭据重新登记公钥。具体操作可参照审核与删除 GitHub SSH 密钥的说明。
复工验收：读取与写入分别验证
不要把 ssh -T 成功当成仓库权限验收。连接测试只帮助确认 SSH 能否识别账号；项目访问还取决于目标仓库、组织策略和该账号的权限。修复后，在真实工作目录中检查远端地址，再用你有权访问的仓库验证需要的读取或写入操作。
- [ ] 确认 Git 命令实际运行的主机、用户和仓库远端地址。
- [ ] 确认执行端使用的密钥与 GitHub 账号中的公钥相对应。
- [ ] 用
ssh -T git@github.com检查连接结果是否识别预期账号。 - [ ] 在获授权的仓库中验证项目实际需要的读取操作。
- [ ] 只有确实需要提交或推送时，才在获授权的仓库验证相应写入权限。
- [ ] 记录密钥存放位置、agent 状态、访问范围和撤销方式；无法确认清理边界的共享环境，不留个人私钥。
把这份记录留在自己的受控位置。下一次会话断开、网络切换或换用另一台设备时，先对照执行主机和密钥位置，再决定是否重做认证；这比在多个设备间反复复制凭据更容易追溯。
如果你的数字游民开发环境需要持续使用 macOS，但当前方案依赖随身携带主机、容易受设备丢失影响，或在共享电脑上难以控制密钥留存，就先比较工作负载与凭据边界。需要临时或按项目使用远程 Mac 时，可查看 VMSPIN 的远程 Mac 访问信息及套餐与计费说明；下决定前，先核实你将使用的执行方式、账号隔离情况和 SSH 密钥撤销路径。若项目要求长期稳定的重负载或必须连接本地物理设备，自购 Mac 可能更合适；不要仅因 SSH 故障就把凭据放进尚未验明边界的主机。