VSCode无法读取远程文件主因是远程目录权限错误：家目录或~/.vscode-server权限不足、属主为root、WSL中/mnt/c路径缺失metadata挂载选项，或.ssh目录及密钥文件权限不符合OpenSSH严格要求（目录700、私钥600）。
VSCode 无法读取远程文件，90% 是因为远程端的目录权限没对上，不是 VSCode 本身的问题，也不是网络不通。
远程连接时 .vscode-server 目录权限被拒绝
VSCode Remote-SSH 首次连接会自动在远程主机上解压并运行 .vscode-server，这个过程需要对用户家目录有完整读写权限。一旦 ~/.vscode-server 或其父目录（比如 ~）被设为只读、属主是 root、或 umask 限制过严，安装就会卡在 “Installing VS Code Server” 并最终报错。
- 先确认当前用户是否真能写家目录：
touch ~/.test && rm ~/.test，失败就说明问题出在这层 - 检查
~/.vscode-server所有者：ls -ld ~/.vscode-server，如果显示root:root，立刻删掉：rm -rf ~/.vscode-server - 别用
sudo code --remote ssh-remote+启动——这会让远端进程以 root 身份尝试写入，反而污染权限 - 某些云主机（如 AWS EC2）默认禁用 root SSH 登录，但如果你用的是普通用户却仍连不上，大概率是该用户家目录权限被手动改成了
755以外的值（比如750），SSH 服务端会拒绝登录
WSL 中 /mnt/c/ 路径下文件“明明可读却报 EACCES”
这是 WSL 特有的跨文件系统陷阱。Windows 的 NTFS 不支持 POSIX 权限，WSL 在挂载 /mnt/c 时靠 drvfs 模拟，但默认不开启元数据支持，导致 chmod 和 chown 失效，VSCode 保存时调用 open(O_RDWR) 就直接被内核拒掉。
- 不要在
/mnt/c/Users/xxx/project里开发——这是最常踩的坑，哪怕终端里echo "ok" > file.txt成功，VSCode 仍可能失败 - 把项目移到 WSL 原生路径，比如
~/projects/myapp，这里chmod +x、git add、npm install全部按预期工作 - 如果非得用 Windows 路径，必须配置
/etc/wsl.conf：[automount] enabled = true options = "metadata,uid=1000,gid=1000,umask=022"
然后关机重启 WSL：wsl --shutdown，否则配置不生效 - 验证是否生效：
ls -l /mnt/c/Users/xxx/test.sh，输出中应显示你的用户名和组，而不是root或一长串数字 UID
Remote-SSH 连接失败提示 “Bad owner or permissions on …/.ssh/config”
OpenSSH 对 .ssh 目录和关键文件（config、id_rsa、known_hosts）有硬性权限要求：目录必须是 700，私钥必须是 600，否则直接拒绝加载——VSCode 的 Remote-SSH 插件底层就是调用 ssh 命令，所以它也会原样抛出这个错误。
- 在远程主机上执行：
chmod 700 ~/.ssh && chmod 600 ~/.ssh/config ~/.ssh/id_rsa - 检查所有者：
ls -l ~/.ssh，确保每一项都属于当前用户，不能是root - Windows 用户注意：
C:\Users\xxx\.ssh在资源管理器里右键 → 属性 → 安全 → 高级 → 禁用继承 → 删除所有继承权限 → 只添加当前用户并赋予“完全控制”，否则 Windows ACL 会覆盖 Linux 权限语义 - 别用
sudo chown -R $USER:$USER ~/.ssh—— 如果你之前用管理员身份生成过密钥，id_rsa可能已被设为644，SSH 会直接忽略它
真正麻烦的从来不是“怎么修”，而是“修完会不会影响其他工具”。比如改了 /etc/wsl.conf，下次同事拉起 WSL 可能发现 Git 提交用户变了；删了 .vscode-server，插件缓存全丢，得重装。这些细节不写进日志，下次遇到还是得重查。
