sublime text 远程编辑安全需严格遵循最小权限原则：禁用密码登录、私钥绝对路径且权限600、sftp-config.json不存敏感信息并加入.gitignore、remote_path精确限定、关闭sync_down_on_open、upload_on_save仅用于静态资源、rsub须限制隧道绑定地址并避免公共环境使用。
Sublime Text 本身不加密传输、不校验远程文件完整性，所谓“安全”全靠你手动堵住 SSH 层和配置层的漏洞——不是开个 upload_on_save 就算安全了。
SSH 认证必须用私钥，禁用密码登录
密码明文填在 sftp-config.json 里等于把服务器大门钥匙贴在项目根目录下。一旦项目被共享或误传，风险直接拉满。
-
password字段必须删掉，哪怕只留空也不写明文 -
ssh_key_file必须是绝对路径，~/.ssh/id_rsa不生效，得写成/home/user/.ssh/id_rsa（Linux/macOS）或C:/Users/User/.ssh/id_rsa（Windows） - 私钥文件权限必须是
600：执行chmod 600 /path/to/id_rsa，否则 SSH 层直接拒绝加载 - 服务器端确认
/etc/ssh/sshd_config中PasswordAuthentication no已启用
sftp-config.json 不能放敏感信息，且路径要受控
这个文件不是“配置”，而是“凭证映射声明”。它一旦泄露，配合私钥就能直连服务器。
- 别把它提交进 Git：加到
.gitignore，内容里也不能出现user或host的泛用值（如prod-server） -
remote_path必须以/开头，且尽量窄：配成"/var/www/myapp/"比"/"或"/var/www/"安全得多 - 如果多人协作，用
sublime-project文件封装配置，而不是让sftp-config.json暴露在项目根目录
upload_on_save 和 sync_down_on_open 是双刃剑
自动同步省事，但也会放大误操作和权限错误的影响范围。
-
sync_down_on_open: true在多人协作时极危险：你双击打开文件，本地副本瞬间被覆盖，刚写的未提交代码直接丢 -
upload_on_save不校验远程文件是否被其他进程修改过（比如 nginx 日志轮转、cron 脚本改配置），保存即覆盖，无冲突提示 - 建议只对静态资源目录（如
/var/www/html/assets/）开启upload_on_save，核心逻辑文件一律手动右键Upload File - 远程文件权限默认变成
600，Web 服务可能读不了；显式加"default_permissions": "644"避免 500 错误
rsub 方案的安全盲区最容易被忽略
rsub 看似“本地编辑”，实则所有内容都经 SSH 加密管道直写远程磁盘——没有中间缓存，也没有二次确认。
- 远程执行
rsub /etc/nginx/nginx.conf，你本地一保存，就直接覆写生产配置，没备份、没 diff、没 rollback - 本地 Sublime 的
rsub插件若被恶意插件劫持，可能把内容发往非预期端口 - SSH 反向隧道端口（默认
52698）若没限制绑定地址（如用了-R 52698:localhost:52698而非-R 127.0.0.1:52698:localhost:52698），可能被局域网其他机器探测利用 - 别在公共终端或 CI 环境运行 rsub，它不校验调用者身份，只要端口通，谁都能推文件
真正安全的远程编辑，不是靠插件开关，而是靠最小权限原则：用专用部署用户（非 root）、限定 remote_path 到子目录、禁用密码、关掉 sync_down_on_open、不把配置文件当文档共享——这些细节漏掉一个，前面所有设置都白搭。
