最稳妥方案是配置免密码 sudo 权限：为部署用户在 /etc/sudoers.d/deploy 中添加 nopasswd 限定命令，禁用 requiretty，避免使用 sudo -i 等 tty 依赖方式，并确保脚本调用全路径命令。
核心思路是：不让 sudo 等待终端输入，而是提前让它“知道”可以无交互执行——要么免密授权，要么跳过 TTY 检查，要么改用不依赖 TTY 的调用方式。
确认并配置免密码 sudo 权限
这是最稳妥、最符合安全规范的做法。非交互环境不能输密码，所以必须让目标命令在 sudoers 中明确允许免密执行。
- 用 Jenkins 或脚本实际运行的用户（如 jenkins 或 deploy）登录服务器，运行：
sudo -n whoami
若返回 root，说明已生效；若报 a password is required，说明权限未配好 - 编辑专属 sudoers 文件（推荐）：
sudo visudo -f /etc/sudoers.d/deploy
添加一行（以 systemctl 为例）：deploy ALL=(ALL) NOPASSWD: /usr/bin/systemctl, /usr/bin/cp, /bin/sh - 确保该文件权限为 0440，且不写
NOPASSWD: ALL—— 这会极大扩大攻击面
避免使用需要 TTY 的 sudo 写法
像 sudo -i、sudo su -、sudo bash 这类命令本质是启动新 shell，强制依赖交互终端，在脚本里必然失败。
- 把脚本内嵌的
sudo systemctl restart nginx改成全路径调用：/usr/bin/sudo /usr/bin/systemctl restart nginx - 如果脚本本身逻辑复杂但只需一次提权，不如外部调用：
sudo bash deploy.sh—— 权限在入口统一提升，脚本内部不再用 sudo - 绝对不要在自动化流程中用
script -qec "..."或ssh -t模拟 TTY，它们不可靠、难维护，且可能引入环境变量污染或连接挂起问题
临时绕过 TTY 检查（仅限调试或受限环境）
如果暂时无法修改 sudoers，且确认风险可控，可调整 sudo 行为策略。
- 编辑
/etc/sudoers（用sudo visudo）：
找到Defaults requiretty这行，加 # 注释掉 - 可选补充：
Defaults:deploy !requiretty
表示只对 deploy 用户禁用 TTY 要求，更精细 - 注意：
Defaults visiblepw在较新版本 sudo 中已废弃，无需设置；也别依赖sudo -S向 stdin 传密码——这在脚本中极不安全，且多数场景下会被拒绝
检查调用链是否隐式触发 TTY 依赖
有时候不是你直接写了 sudo，而是调用的工具（如 ansible、docker-compose、某些封装脚本）内部执行了 sudo，却没处理非交互上下文。
- 在日志或 stderr 中搜索关键词：
no tty present、a password is required、sorry, you must have a tty - 用
strace -e trace=execve sudo -n true 2>&1 | grep -i tty查看底层是否尝试访问 /dev/tty - 若使用 paramiko、fabric 等库远程执行，不要用
exec_command()直接跑 sudo 命令；应改用invoke_shell()并手动分配 pty（仅必要时），或更推荐：先用 ssh 密钥免密登录，再在远端确保 sudo 权限已配好
