// 此模板仅供参考，如果不适用可以修改
发送snmpwalk命令报错认证失败，已确认密码无误
snmpwalk -v3 -l priv -a SHA256 -x AES -u Administrator -A -X 1.3.6.1.2.1.4.20
NA
重启之后低概率出现该问题
snmp命令发送成功
snmp发送失败
已定位到根因，/dev/shm/tallylog目录的用户组是secbox，导致snmp命令打开文件失败，改成snmpd_user之后就发送成功了
期望能在1/14前给出定位结论
答案内容由AI生成，仅供参考：
执行 snmpwalk 命令时出现“Authentication failure（认证失败）”错误，提示用户密码、团体名或密钥不正确：
snmpwalk -v3 -l priv -a SHA256 -x AES -u Administrator -A [模糊字符] -X [模糊字符] 1.[模糊数字].6.1.2.1.4.20
snmpwalk: Authentication failure (incorrect password, community or key)
尽管已确认用户名和密码正确，且配置无误，但仍无法完成 SNMPPv3 认证。此问题在系统重启后低概率复现。
authPriv 模式（SHA256 认证 + AES 加密）Administratorsnmpwalk 命令；SNMP 命令应成功执行并返回对应 MIB 节点信息。
命令返回 Authentication failure 错误，即使凭据正确也无法通过认证。
日志中反复出现以下关键错误信息：
pam_tally_ext.c(78): open faillog file failed.
user_login_lock.c(152): open tally file error
[user login lock] call get_pam_tally failed, ret: -1
进一步排查发现 /dev/shm/tallylog 目录权限异常：
# 原始状态（错误）
drwxrwxrwt 19 secoxx root 640 ... /dev/shm/tallylog/
# snmpd 进程运行身份
ps aux | grep snmpd
snmpd_u+ 50469 ... -g snmpd_user -u snmpd_user
说明：
snmpd 守护进程以用户 snmpd_user 和组 snmpd_user 运行；/dev/shm/tallylog 的属组为 root，而非 snmpd_user，导致进程无权访问该目录下的认证状态记录文件。根本原因：
/dev/shm/tallylog目录的用户组权限配置错误，导致snmpd进程无法访问其所需的状态文件，从而引发认证子系统初始化失败，最终返回“Authentication failure”错误。
PAM 子系统依赖：
即使 SNMPv3 使用独立的 USM 用户数据库进行身份验证，部分实现中仍会调用 PAM（Pluggable Authentication Modules）模块用于账户锁定、登录尝试计数等安全控制。
tallylog 文件作用：
/dev/shm/tallylog 是用于临时存储用户登录失败次数的共享内存目录，由 pam_tally 或类似模块管理。SNMP 守护进程需读写此目录以维护用户尝试状态。
权限冲突：
当 /dev/shm/tallylog 的属组为 secbox 或 root，而 snmpd 以 snmpd_user 组身份运行时，因缺少读写权限，pam_tally 无法打开或创建对应用户的 tally 文件。
认证流程中断：
PAM 初始化失败 → get_pam_tally 调用返回 -1 → 认证流程被提前终止 → 外部表现为“Authentication failure”，即使密码本身正确。
安全设计原则：
系统统一返回“认证失败”而非具体错误细节（如“文件打开失败”），是为了防止信息泄露，符合安全加固规范。
修改 /dev/shm/tallylog 目录的属组为 snmpd_user：
# 修改目录属组
chown -R :snmpd_user /dev/shm/tallylog
# 或指定用户和组
chown secoxx:snmpd_user /dev/shm/tallylog
操作后验证：
# 查看权限
ll /dev/shm/tallylog
drwxrwxrwt 19 secoxx snmpd_us 640 ... ./
# 再次执行 snmpwalk 命令
snmpwalk -v3 -l priv -a SHA256 -x AES -u Administrator -A xxx -X xxx 1.3.6.1.2.1.4.20
# 👉 成功返回数据
启动脚本加固：
在 snmpd 启动脚本中加入权限检查逻辑，确保 /dev/shm/tallylog 权限正确。
自动化配置管理：
if [ "$(stat -c %G /dev/shm/tallylog)" != "snmpd_user" ]; then
chown :snmpd_user /dev/shm/tallylog
fi
服务依赖配置：
确保 snmpd 服务在相关安全模块（如 PAM、user_login_lock）初始化完成后再启动。
日志增强建议：
当前版本缺乏对底层文件访问失败的详细日志输出。建议增加调试日志级别选项，便于快速定位此类权限问题。
结论：该问题并非真正的“密码错误”，而是由于 /dev/shm/tallylog 目录组权限不匹配 导致 SNMP 认证流程因 PAM 初始化失败而中止。将目录属组更改为 snmpd_user 后问题解决，认证恢复正常。
相关链接：
你说的是 这个问题么
不是同一个问题，这是两个问题，这个是直接认证失败了，另一个是认证成功，但是命令内部转发的时候失败了
就是这个日志，一毛一样的
@Larry_Li 这个问题能看出问题点吗
从日志中看不出来是什么导致了/dev/shm/tallylog目录的权限错误。我们本地没有复现这个问题。 你手动恢复权限后，还能复现问题不？
没有复现了，重启BMC之后可以修复这个问题，概率性出现这个问题，我们测试已经测出了两次
当出现这个问题的时候， 一键收集下日志， 并提供下给我们
日志太大上传不上，这是LogDum，压缩包无法上传，你把后缀去掉解压就行：
LogDump.zip.txt (8.7 MB)
正常情况下/dev/shm/tallylog目录用户组是snmpd_user，异常情况是sec_box
测试复现的两次，执行的哪些用例，哪些什么操作，麻烦提供一下。
我看了测试的自动化脚本，就是重启BMC之后，就开始发snmp命令去查询一些数据，但在某一次就出现认证失败
好的
你使用的 25.09 版本已EOS，不再支持。请升级到25.12 LTS 版本
