linux无开箱即用ssh全操作录屏功能，需分层实现：auditd提供内核级命令审计（最可靠），prompt_command辅助记录bash命令，rsyslog外发日志防篡改，生产环境应接入堡垒机满足合规要求。
Linux 本身不提供开箱即用的“SSH 全操作录屏”功能，所谓“记录所有操作”，实际是分层实现的：命令级靠 auditd 或 PROMPT_COMMAND，会话级靠堡垒机或 ttyrec，日志归集靠 rsyslog。直接改 .bash_history 或只开 LogLevel VERBOSE 都无法满足审计要求——前者可被用户清空，后者只记登录/登出，不记具体命令。
auditd 记录 execve 系统调用（最可靠命令级审计）
这是内核级审计，绕过 shell 层，连 sudo、su、脚本里执行的命令都会被捕获，且不可绕过或删除（除非 root 主动清空 audit 日志）。
- 确认
auditd已安装并运行：systemctl is-active auditd，若为inactive，先执行systemctl enable --now auditd - 添加规则监听所有命令执行：
auditctl -a always,exit -F arch=b64 -S execve -k user_commands（x86_64 系统）；如需兼容 32 位程序，再加一条-F arch=b32 - 规则持久化：将上述
auditctl命令写入/etc/audit/rules.d/user-commands.rules，然后augenrules --load - 查日志用
ausearch -k user_commands | aureport -f -i，注意exe字段是二进制路径，cwd是执行目录，comm是命令名——不是bash里的别名或函数 - 常见坑：
execve不记录命令输出，只记录“谁在哪儿执行了什么”；若用户用python -c "import os; os.system('rm -rf /')"，audit 只记python，不记rm，需配合其他手段
/etc/profile.d/ 中用 PROMPT_COMMAND 实时追加命令（轻量级、易部署）
适合快速上线基础命令记录，但依赖用户使用交互式 bash/sh，且对非 bash shell（如 zsh、fish）或直接 ssh user@host command 形式无效。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 创建
/etc/profile.d/audit_cmd.sh，内容包含：export HISTTIMEFORMAT="%Y-%m-%d %T "和export PROMPT_COMMAND='history -a' - 为防覆盖，建议额外加一行：
export HISTFILE="/var/log/bash_history_$(whoami)"，把每个用户历史写到独立文件，避免多终端冲突 - 权限必须设为
644，否则普通用户可能因读不到脚本而失效；同时确保/var/log/下目标目录可写（如chmod 1777 /var/log/bash_history_dir） - 该方式记录的命令仍存在被篡改风险（用户可改
HISTFILE或 unsetPROMPT_COMMAND），仅作辅助，不可替代auditd - 注意
history -a不记录当前行命令，而是下一行才写入——所以最后一条命令总在退出时才落盘
rsyslog 转发命令日志到远程服务器（解决本地日志被删风险）
单机审计最大的问题是日志和被审计主机在同一台机器上，root 权限可一键清空。必须把关键日志外发，且用 UDP/TCP 加密通道（如 RELP）传输。
- 在客户端配置
logger打点：export PROMPT_COMMAND='logger -p local6.info "user=$(whoami) cmd=$BASH_COMMAND from=$SSH_CLIENT"'，其中local6是自定义 facility，避免污染 auth 日志 - 在
/etc/rsyslog.conf末尾加：local6.* @192.168.10.100:514（UDP）或@@192.168.10.100:601（TCP），IP 替换为你的日志服务器地址 - 服务端 rsyslog 必须监听对应协议和端口，并用
$template定义格式，否则收到的日志可能无时间戳、无主机名 - 不要用
auth.*直接转发，因为/var/log/secure里混有密码尝试、PAM 消息等噪声，审计时难过滤 - 测试是否生效：
logger -p local6.info "test"，然后在服务端tail -f /var/log/remote_audit.log查看
堡垒机才是生产环境真正的审计入口
如果你的目标是满足等保、ISO27001 或内部合规要求，重点不该放在“怎么让 Linux 自己记”，而应检查“Linux 是否已接入堡垒机”。所有审计能力——命令回放、剪切板捕获、SFTP 文件审计、多账号隔离——都由堡垒机侧完成，Linux 服务器只需保证 SSH 可连通即可。
- 验证连接性：
ssh -p 22 -o ConnectTimeout=5 user@192.168.1.100，失败则排查防火墙、sshd_config中的PermitRootLogin、AllowUsers等限制 - 堡垒机添加资产时，“认证方式”必须与 Linux 实际一致：若用密钥，私钥必须是 PEM 格式（
-----BEGIN RSA PRIVATE KEY-----），OpenSSH 新格式（-----BEGIN OPENSSH PRIVATE KEY-----）会被拒绝 - 字符审计开关常被遗漏：即使资产添加成功，若堡垒机后台没开启“命令审计”策略，所有操作依然不会入库——这不是 Linux 配置问题，是堡垒机策略开关没点开
- 审计日志中
user_name来自堡垒机账号（如zhangsan@company.com），不是 Linux 的root。多人共用一个堡垒机账号，等于放弃责任认定 - 真正难的是权限收敛：堡垒机可配命令白名单（如只允许
ls、cat），但若运维人员有 root 权限且能执行bash，白名单就形同虚设——得靠auditd+ 堡垒机双控
