本文对比 Tabby 与 Termius 在 SSH 使用场景下的设计理念、安全模型与长期可维护性。文章不涉及具体个人环境细节，聚焦工具本身的结构性差异。 一、问题背景 在多主机运维、个人服务器或实验环境中，SSH 客户端往往会逐渐从“工具”演变为“基础设施的一部分”。 这时，一个关键问题会浮现： SSH 客户端应当只是 OpenSSH 的外壳，还是一个自成体系的连接管理平台？ Tabby 与 Termius，正好代表了这两种截然不同的路线。 二、核心设计理念对比 Tabby：OpenSSH 的 UI 外壳 Tabby 的核心定位非常克制： 换句话说： Tabby 不试图“接管 SSH”，而是选择“服从 SSH”。 Termius：自包含的 SSH 平台 Termius 的设计目标明显不同： 在 Termius 中： SSH 不再是系统能力，而是应用能力。 三、安全模型差异 Tabby 的安全边界 Tabby 的安全边界在操作系统层： Tabby 本身： 这意味着： Tabby 的安全性 …
背景 在现代 Linux 系统中，SSH 公钥认证已成为远程登录与自动化运维的基础设施之一。随着密码学实践的演进，Ed25519 已成为 OpenSSH 官方推荐的默认算法。本文记录在 Linux 环境下生成 Ed25519 SSH key 的最小且安全做法，并澄清若干常见误解，重点面向： 全文仅涉及事实与机制，不包含个人偏好或架构建议。 一、推荐的算法选择 当前时间节点（2025–2026 年前后），在 OpenSSH 环境中： 因此，以下示例均以 Ed25519 为前提。 二、生成 Ed25519 SSH Key 的标准命令 在 Linux 命令行下，生成一把偏安全取向的 Ed25519 key： 参数说明 执行后将生成： 三、关于 passphrase 生成过程中会提示输入 passphrase： 是否设置 passphrase 不影响 key 的数学有效性，但会影响私钥泄露后的风险等级。 四、公钥最后的“名字”是什么？ 典型的 Ed25519 公钥内容如下： 其结构为： 其中： …
目标：在 Android 平台上选择一个 长期可用、离线、可控 的 SSH 登录方案，避免云绑定、避免停更风险，并与桌面端使用习惯保持一致。 一、问题背景 在 Android 上寻找 SSH 客户端时，常见诉求包括： 部分流行客户端在实际使用中暴露出以下问题： 因此需要重新评估 Android 上 SSH 客户端的长期可行性。 二、评估维度 本文主要从以下维度进行筛选： 其中，前 3 条为硬条件。 三、常见方案分析 1. 商业型一体化客户端 特点： 问题： 结论： 不适合作为长期、可控的基础设施工具。 2. 已停止维护的 Android SSH 客户端 特点： 问题： 结论： 停更即不可用，应直接排除。 3. 终端型方案（如完整 Linux 用户态环境） 特点： 问题： 结论： 适合重度用户或统一桌面/移动端工作流，但不符合“轻量点击登录”的需求。 四、最终选择：轻量、离线、长期可用的 SSH …
背景 在使用 FRP（Fast Reverse Proxy）进行内网穿透时，FRPS（服务器端）的通信端口配置直接影响系统的稳定性、安全性以及后续的运维复杂度。 随着 FRP 新版本引入基于 QUIC 的传输方式，配置项中新增了 QUIC 相关监听参数，这使得服务器端可能同时存在多种控制通道实现方式，有必要对其协议属性与实际影响进行明确分析。 QUIC 监听端口的协议属性 结论明确： FRPS 中用于 QUIC 的监听端口基于 UDP 协议 原因在于： 协议层级关系如下： 因此： 传统控制端口与 QUIC 控制端口的差异 FRPS 提供两种功能等价的控制通道实现方式： 项目 传统控制通道 QUIC 控制通道 底层协议 TCP UDP 连接可靠性 由 TCP 提供 由 QUIC 协议实现 网络兼容性 高 依赖 UDP 质量 运维复杂度 较低 …
事件背景 近期，日本大型企业 Asahi 集团披露其内部系统遭到勒索软件攻击。多个安全媒体确认，该事件并非简单的自动化攻击，而是一次具备明确目标、持续渗透和横向移动特征的 人工入侵型勒索事件。攻击者被认为与 Qilin 勒索软件组织有关。 从已公开的信息可以确认： 目前并无可靠公开信息披露具体赎金金额，亦无法确认受害方是否支付赎金。 是否会被法律追责 从法律层面看，勒索软件攻击属于严重刑事犯罪；但在现实中，类似 Qilin 的跨国勒索组织 极少真正受到司法追责。主要原因包括： 因此，“违法”与“能否被追责”在现实世界中存在明显落差。 入侵路径分析：SSH 还是 Web？ 截至目前，没有公开证据确认 Asahi 是通过 SSH 还是 Web 服务被直接攻破。但结合企业环境特征与勒索组织的常见攻击模式，可以做出较为可靠的排除与判断。 排除可能性较高的路径 更可能的真实入口 攻击者能够长期稳定地外传大量数据，本身就说明其获得的是 持续、可信的内部访问权限。 MFA（多因素认证）的现实意义 MFA（Multi-Factor Authentication，多因素认证）指登录验证不再只依赖单一密码，而是组合以下至少两类要素： 在现实安全模型中，MFA 的作用并不是“提高一点安全性”，而是 直接切断绝大多数常见入侵路径： 因此，在 VPN、远程管理、邮件系统、云控制台等关键入口未启用 MFA 的情况下，企业几乎处于高风险状态。 一个重要的现实结论 从大量企业勒索案例可以观察到： 攻击者并不依赖“技术上一定能攻破”，而是选择最省成本、最容易得手、最容易横向扩散的入口。 这意味着，安全的核心并不是假设攻击者会被法律阻止，而是： 总结 Asahi 事件并不说明“大企业不懂安全”，而是揭示了现实世界的安全边界： 从工程视角看，多因素认证 + 最小入口原则，依然是对抗现实勒索威胁最有效、性价比最高的防线。
一、问题背景 在使用 OpenWrt 作为家庭或个人网络核心时，一个很自然的问题是： LuCI 管理界面是否支持两步验证（2FA / TOTP）？ 这个问题在“公网 IP + 自建服务 + 长期运行”的场景下尤其常见，因为一旦路由器被入侵，后果往往是灾难性的。 本文将从事实、原因和现实可行的安全实践三个层面，系统回答这个问题。 二、结论先行 结论很明确： OpenWrt 官方的 LuCI 管理界面，并不原生支持两步验证（2FA）。 而且这并不是功能缺失，而是一个有意的设计取舍。 三、为什么 LuCI 没有原生 2FA LuCI 的设计目标与典型的 Web 后台系统完全不同： 技术上，LuCI 的认证模型通常是： 在这个模型下： 因此，官方并没有为 LuCI 设计内建 2FA，也没有计划添加。 四、一个重要认知：LuCI 是否真的“需要”2FA？ 在实际运维中，几乎没有人依赖 LuCI 自身来承担公网安全责任。 原因很简单： 真正的安全，从来不是在“最后一层登录页”加功能，而是从入口设计开始。 对 LuCI 而言，安全的关键问题不是： 而是： 五、更现实、更可靠的安全实践（推荐方案） 以下方案按照安全收益 …
摘要 在一次服务器环境部署过程中，使用 v2rayA 管理代理服务时，先后遇到了两个相互叠加的问题： 这两个问题在受限网络环境下相互影响，导致服务反复启动失败。本文完整记录了问题出现、逐步排查、原因定位以及最终解决的全过程，并总结出一套在类似环境中稳定、可复现的处理方案。 全文已严格脱敏，仅保留必要的技术事实与因果关系。 一、问题背景 在该前提下进行常规部署，出现了一系列连锁问题。 二、问题一：geoip.dat / geosite.dat 缺失 1. 现象 服务层日志提示： geoip.dat or geosite.dat file does not exists 2. 初步判断 根据 v2ray 的运行机制： 因此，问题并非配置错误，而是 资产文件获取失败。 3. 自动下载失败的真实原因 进一步结合环境特征分析后，可以确认： 由此形成典型的“鸡生蛋”死循环： 在该环境下，自动修复机制在理论上无法成功。 4. 解决方式：手动上传 geo 文件 在可访问 GitHub 的环境中下载： 上传并放置到 v2ray 默认资产目录： 重启服务（关键）： 此时： 问题一解决。 三、问题二：软件源安装的 v2ray-core 版本过低 …
在 OpenWrt 路由系统中，SSH 默认使用 Dropbear 作为服务端，并允许密码登录。在具备公网访问、端口转发或远程运维场景下，切换为仅密钥登录可以显著降低暴力破解与误入侵风险。 本文记录 OpenWrt 中将 SSH 登录方式由“密码 + 密钥”调整为“仅密钥”的完整过程，并附带常见注意事项。 一、OpenWrt 中 SSH 的配置位置 OpenWrt 提供两种主要配置方式： 底层服务均由 Dropbear 控制。 二、通过 LuCI Web 界面配置（直观方式） 配置路径 关键设置项 保存并应用即可生效。 三、通过命令行配置（可控性更高） 1️⃣ 准备 SSH 公钥（客户端） 在客户端生成或查看公钥，例如： 复制输出的整行内容。 2️⃣ 写入 OpenWrt 的 authorized_keys 登录 OpenWrt（此阶段仍保留密码登录）： 创建并编辑公钥文件： 示例内容： 设置正确权限（非常重要）： 3️⃣ 禁用 SSH 密码认证 …
一、场景说明 在一个典型的家庭自托管环境中，网络结构通常具备以下特征： 邮件服务器并非面向公众提供邮箱服务，而是用于： 是否接收来自互联网的外部邮件，并非初始刚性需求。 二、最初遇到的现实限制 1. VPS 方案的端口问题 常见的做法是使用一台低成本 VPS 作为公网入口或中转节点。然而在实践中发现： 即便 VPS 成本低廉，只要 25 端口被封禁，在邮件接收场景下就会出现功能性不可用的问题。 2. 家庭宽带（MAP-E / IPv4 over IPv6）的天然约束 在未申请固定 IPv4 的家庭宽带环境中，常见网络形态包括： 在这种情况下： 因此，“直接在家庭网络中接收外部邮件”在默认条件下并不可行。 三、被认真评估的解决方案：家庭固定 IPv4 为了解决端口受限问题，评估了运营商提供的固定 IPv4 服务。该方案在技术层面具有明确优势： 成本结构（已脱敏） 与现有 VPS（月费约 500 日元）相比，固定 IP 带来了额外且长期的成本。 四、关键转折：重新界定真实需求 在进一步分析后，一个核心问题被重新提出： 邮件服务器当前是否真的需要接收来自外部的邮件？ 对邮件系统的实际用途进行梳理后，可以明确： 由此可以得出一个重要结论： “无法接收外部邮件”并不会影响当前系统的实际功能价值。 五、工程视角下的理性判断 1. 固定 IP 的技术价值是确定的 …
在自建服务（如 Web、SSH、邮件、游戏服务器等）的过程中，是否能够识别真实访客 IP 是一个非常关键、但常被忽略的问题。本文对两种常见方案进行对比分析： 重点讨论：后端服务究竟能看到什么来源 IP。 一、问题背景 常见的家庭或个人服务器部署方式主要有两类： 两种方案在“能否访问服务”上都可行，但在访问者 IP 可见性上存在本质差异。 二、结论先行 使用公网 IPv4 + 路由器端口转发时，局域网服务通常可以直接看到访问者的真实公网 IP。 使用 VPS + FRP 时，局域网服务只能看到 VPS 的 IP，无法直接获得真实访客 IP。 这是由网络连接模型决定的，而非配置错误。 三、公网 IP + 端口转发的工作机制 端口转发的本质是 DNAT（Destination NAT，目标地址转换）： 关键点： 因此： 四、实际表现 在这种架构下： 这是网络层原生行为，无需额外配置。 五、VPS + FRP 的连接模型 FRP 属于反向隧道工具，其连接关系为： 在该模型中： 因此在内核层面： 这是设计决定的，无法通过简单配置绕过。 六、FRP 是否能“传递”真实 …