用 Python 写个 SSH 蜜罐，来一场密码字典的“草船借箭”
内容提要
作者用 Python 和 AsyncSSH 在自有 Ubuntu 机器上搭建 SSH 蜜罐，被动记录认证尝试并一律拒绝。不到 22 小时内记录约 2.3 万次认证尝试、65 个来源 IP 和 321 种用户名。密码前三为 123456、12345678、password，但去重后密码种类极多，头部占比不高。root 占认证尝试约 97.7%，少数来源贡献约 96.7% 的尝试。作者强调蜜罐仅用于授权环境观察，结果受位置、时长和来源影响，不能当作全网密码字典；生产服务器仍应使用密钥认证并收紧管理入口。
延伸解读
统计口径决定结论：别把连接数当攻击者数
文章明确区分了连接数、认证尝试数和来源IP数：一个连接可发生多次认证尝试，来源IP也不等于攻击者人数。本次23,354个连接对应23,285次认证尝试，65个来源IP中前两个就贡献了约96.7%的尝试。读者在引用类似蜜罐数据时，应先确认统计的是连接、认证事件还是独立来源，否则容易把少数高频来源误读为大规模攻击。
密码榜的“头部”并不代表字典全貌
虽然123456、12345678和password位列前三，但分别只有23、14、13次；带密码字段的23,274条事件中，不同密码字符串多达19,855种。这说明头部常见密码占比很低，大量候选值只出现一两次。作者提醒，这些去重结果可能包含测试值、随机字符串或工具生成值，不能直接当作高质量密码字典使用。
蜜罐只负责观察，生产安全仍需密钥认证
该蜜罐对所有认证路径一律返回失败，不提供Shell、文件传输或转发入口，因此没有登录成功率可算。作者强调，结果受机器位置、暴露端口、观察时长和少数高频来源影响，还混有本机测试，不能代表全网密码习惯。对生产服务器，文章的建议仍是使用密钥认证、确认可登录后再禁用密码登录，并收紧管理入口。
公网实验的边界：隔离、限权和日志保护
文章列出几项不能省略的提醒：蜜罐要与真实管理SSH分开，避免覆盖正在使用的端口；用独立低权限用户和隔离环境运行，不把“永远拒绝登录”当作软件无漏洞的保证；限制出站访问并控制资源、安排日志轮转；日志含明文凭据，不上传原始日志，目录权限和主机私钥都要保护。这些限制说明，小脚本适合观察，但长期公网运行需要额外加固。
Q&A
用 Python 搭建 SSH 蜜罐需要哪些库和基本环境？
作者使用 Python 3.12.3 和 AsyncSSH 2.24.1，基于 asyncio 实现 SSH 服务端认证回调。程序默认监听 2222 端口，通过 pip 安装依赖后运行 honeypot.py 即可。
SSH 蜜罐是怎么记录到密码的？是不是抓到了明文？
不是抓取网络明文。SSH 传输本身是加密的，但蜜罐作为接收认证请求的服务端，AsyncSSH 库会把客户端提交的密码交给认证回调，脚本在回调中记录后一律返回失败。
蜜罐运行不到 22 小时记录到了哪些主要数据？
记录到 23,354 个连接、23,285 次认证尝试、65 个来源 IP 和 321 种用户名。密码尝试前三为 123456（23 次）、12345678（14 次）、password（13 次）。root 用户名被尝试 22,744 次，约占 97.7%。
为什么两万多次认证尝试中密码第一名才出现 23 次？
对原始 JSONL 统计发现，带密码字段的事件有 23,274 条，不同密码字符串多达 19,855 种，很多候选值只出现一次或少数几次，头部密码并未占据全部流量。这些去重结果可能包含测试值、随机字符串或工具生成的候选值，不能直接当作高质量密码字典。
蜜罐记录到的来源 IP 数量能代表攻击者人数吗？
不能。来源 IP 数不等于攻击者人数或组织数量。本次样本中前两个来源分别有 19,501 次和 3,015 次认证尝试，合计约占总数的 96.7%，说明结果主要由少数高频来源决定，不能看到 65 个 IP 就以为有 65 份独立字典。
这个蜜罐脚本在安全上需要注意哪些事项？
蜜罐应与真实管理 SSH 分开，使用独立低权限用户和隔离环境运行；限制出站访问，控制资源并安排日志轮转；日志含明文凭据，不上传原始日志，保护目录权限和主机私钥；不要将“永远拒绝登录”当作软件无漏洞的保证。生产服务器仍应使用密钥认证并收紧管理入口。
