Ansible执行Shell脚本时无法找到.ssh目录，复制authorized_keys失败问题求助

咱们一步步来排查你遇到的这几个问题，这些基本都是Ansible执行环境和你手动操作的终端环境不一致导致的常见坑：

这个错误的核心原因是~spider/.ssh要么不存在，要么不是目录——直接用cp复制文件到一个不存在的目录路径时，系统会尝试把这个路径当成文件创建，自然会报错。

你可以先确保目标目录存在，再执行复制：

mkdir -p ~spider/.ssh && cp ~butterfly/.ssh/authorized_keys ~spider/.ssh/

加-p参数是为了确保父目录（如果不存在）也会被创建，且如果.ssh已经存在不会抛出错误。

另外别忘了设置SSH要求的严格权限，否则后续spider用户可能无法通过密钥登录：

chmod 700 ~spider/.ssh && chmod 600 ~spider/.ssh/authorized_keys

这大概率是Ansible执行环境的路径解析或用户身份和你手动终端不一致导致的，试试这几个排查方向：

• 放弃用~简写，直接用绝对路径。比如把~butterfly/.ssh改成/home/butterfly/.ssh——Ansible的shell模块在非交互式执行时，对~的解析逻辑可能和你手动登录的交互式终端不一样。
• 确认Ansible执行任务的用户身份。在你的Ansible任务里加一条whoami命令，看看输出的用户是不是和你手动终端登录的用户一致（比如是不是root）。如果playbook没指定remote_user或become: yes，可能是用默认普通用户执行，权限范围和root不一样。
• 检查命令参数是否正确。确保Ansible里的ls命令确实带了-a参数（显示隐藏文件），比如直接写ls -altr /home/butterfly/用绝对路径执行。

这个也是环境变量不一致的锅：你手动登录的终端会加载用户的profile/bashrc配置，里面可能设置了时区；但Ansible执行的是非交互式shell，不会加载这些配置，导致显示的时间戳是系统默认时区，看起来像是旧数据。

解决方法很简单：

• 在命令前手动加载环境配置，比如source /etc/profile && ls -altr /home/butterfly/
• 或者直接指定时区执行，比如TZ='Asia/Shanghai' ls -altr /home/butterfly/（替换成你实际使用的时区）
• 也可以在Ansible的shell模块里指定用bash执行，确保加载完整环境：

  - name: 查看butterfly目录内容
    shell: ls -altr /home/butterfly/
    executable: /bin/bash
  

既然用了Ansible，其实没必要写Shell脚本，原生模块会自动处理路径、权限、环境这些坑，更可靠也更容易排查问题：

• 创建spider用户的.ssh目录：

  - name: 为spider用户创建.ssh目录
    file:
      path: /home/spider/.ssh
      state: directory
      owner: spider
      group: spider
      mode: '0700'
  

• 复制authorized_keys文件：

  - name: 从butterfly复制authorized_keys到spider
    copy:
      src: /home/butterfly/.ssh/authorized_keys
      dest: /home/spider/.ssh/authorized_keys
      owner: spider
      group: spider
      mode: '0600'
      remote_src: yes
  

• 查看butterfly目录的所有文件（包括隐藏文件）：

  - name: 列出butterfly家目录的所有文件
    find:
      path: /home/butterfly/
      hidden: yes
    register: butterfly_files
  - debug:
      var: butterfly_files
  

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