关键是从源头禁用命令行传参式密码输入,改用配置文件、STDIN交互或凭据注入;终端侧通过HISTCONTROL、history-ignore-patterns及unset HISTFILE屏蔽记录;堡垒机侧实施正则拦截、二次确认与全量审计。

在堡垒机与 Linux 终端双重加固环境下,防止密码明文进入命令历史,关键不是“删掉已输入的”,而是从源头切断密码以明文形式出现在 shell 命令行中的路径。历史记录(~/.bash_history)只是表象,真正风险在于:密码被 echo "pwd123" | ssh user@host、mysql -u root -p'123456' 这类写法直接暴露在进程参数、ps 输出、审计日志甚至系统内存中。
禁用命令行传参式密码输入
几乎所有带 -p 或 --password 参数直传密码的工具(如 mysql、psql、redis-cli、curl)都存在明文泄露风险。必须改用安全交互或凭据注入方式:
- MySQL/PostgreSQL:使用
~/.my.cnf或~/.pgpass文件,权限设为600,内容仅含 host/user/pass/port,不出现于命令行 - Redis:改用
redis-cli -a→ 禁用;改用redis-cli --no-auth-warning -u redis://:pass@host:port→ 仍不推荐;最佳是启用 ACL 并配合redis.conf中的requirepass+ socket 认证,或通过stdin交互式输入:printf "%s" "$PASS" | redis-cli -a "" --no-auth-warning - 通用原则:任何支持
STDIN或配置文件的工具,一律禁用命令行密码参数。检查 man 手册确认是否有--defaults-file、--config、--login-path等替代方案
终端侧:关闭敏感命令记录 + 清理已有痕迹
即使用户没输错,只要命令含密码字符串,就会进 history —— 所以不能只靠“别手滑”,而要系统性屏蔽:
Linux 安全审计工具,检查 SSH 配置、开放/监听端口、防火墙规则(ufw/iptables/nftables)、失败登录尝试、sudoers 权限...
- 在
~/.bashrc或/etc/skel/.bashrc中设置:HISTCONTROL=ignorespace:ignoredups,再配合 alias 强制空格前缀(如alias mysql=' mysql'),使带密码的命令因开头空格不入 history - 全局禁用特定命令记录:在
/etc/inputrc添加set history-ignore-patterns "*.sh *.py *-p* *pass* *pwd*"(注意该功能依赖 readline 版本,建议搭配下一条使用) - 对已存在的
.bash_history,执行history -c && cat /dev/null > ~/.bash_history清空;但更关键是确保新会话不产生——堡垒机登录后首次执行unset HISTFILE可临时禁用记录(需结合堡垒机策略允许)
堡垒机侧:策略级拦截与审计兜底
堡垒机不是“透明通道”,而是可主动干预的管控节点。利用其能力实现纵深防护:
- 在运维安全中心(如腾讯云堡垒机、JumpServer)的“命令控制策略”中,配置正则规则拦截含
-p[[:space:]]*、--password=、password:、\".*[Pp][Aa][Ss][Ss].*\"的命令,直接拒绝执行并告警 - 开启“高危命令二次确认”,对匹配
mysql|psql|ssh.*-o.*PasswordAuthentication=yes等模式的命令,强制弹窗要求审批或 MFA 验证 - 审计日志必须开启“命令内容全量采集”(非仅命令名),并在后台启用 NLP 敏感词扫描,自动标记含密码特征的会话,触发人工复核流程
替代路径:用凭据注入代替人工输入
终极解法是让密码根本不出现在用户终端界面和命令流中:
- 对脚本任务:使用
systemd --scope --property=EnvironmentFile=/run/credentials/app.env your-script.sh,凭据由堡垒机或 KMS 注入至/run/credentials/下加密挂载点,脚本读取环境变量而非硬编码 - 对交互式管理:堡垒机集成
pass或 Vault CLI,点击按钮自动填充到目标会话,填充后立即清空剪贴板,并禁止复制粘贴操作(堡垒机 UI 层限制) - 数据库等服务:启用 PAM 插件(如
auth_pam_tool)或 LDAP 统一认证,让密码验证走集中身份平台,本地不存也不输密码










