Category: SSH

背景 一台 Arch Linux KDE 桌面环境中使用 Tabby 作为日常终端和 SSH 客户端。系统中维护了多个 SSH 连接配置，其中包括两台通过公网入口和端口转发访问的树莓派。 某次调整树莓派系统后，Tabby 连接这两台树莓派时同时报错： 奇怪的是，其他服务器在 Tabby 中都能正常连接，只有这两台树莓派出问题。 一开始很容易怀疑是 SSH 配置、host key、known_hosts、端口映射或树莓派系统本身的问题。但最终排查结果证明：问题并不在服务器端，也不在 .ssh/config，而是 Tabby 某个版本的内置 SSH 实现存在兼容性问题。 初始现象 Tabby 中通过 SSH profile 连接树莓派时失败，界面显示类似： 但直接在系统终端中执行 OpenSSH 命令可以正常连接： 进入系统后，两个远程系统都正常响应，说明： 更关键的是，在 Tabby 中打开一个普通本地 shell，再手动执行系统 ssh 命令，也可以正常连接两台树莓派。 这说明问题不是 Tabby 作为终端模拟器的问题，而是 Tabby 自己的 SSH profile / …

本文对比 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 …

在 OpenWrt 路由系统中，SSH 默认使用 Dropbear 作为服务端，并允许密码登录。在具备公网访问、端口转发或远程运维场景下，切换为仅密钥登录可以显著降低暴力破解与误入侵风险。 本文记录 OpenWrt 中将 SSH 登录方式由“密码 + 密钥”调整为“仅密钥”的完整过程，并附带常见注意事项。 一、OpenWrt 中 SSH 的配置位置 OpenWrt 提供两种主要配置方式： 底层服务均由 Dropbear 控制。 二、通过 LuCI Web 界面配置（直观方式） 配置路径 关键设置项 保存并应用即可生效。 三、通过命令行配置（可控性更高） 1️⃣ 准备 SSH 公钥（客户端） 在客户端生成或查看公钥，例如： 复制输出的整行内容。 2️⃣ 写入 OpenWrt 的 authorized_keys 登录 OpenWrt（此阶段仍保留密码登录）： 创建并编辑公钥文件： 示例内容： 设置正确权限（非常重要）： 3️⃣ 禁用 SSH 密码认证 …

在 Linux 桌面环境中，系统已经设置了日语键盘布局，但部分应用（如 Termius）依然显示为英文键盘布局，导致输入符号错位。这个问题的根源在于 系统级键盘配置未正确传递到 X11，而 Electron 应用（Termius 属于此类）直接读取 XKB 配置，因未设置而退回到默认的美式键盘。 问题表现 临时解决方法 通过 setxkbmap 命令可以立即切换键盘布局： 执行后，Termius 中的键盘映射立即恢复正常。但该方法在重启或重新登录后会失效。 永久解决方法 使用 localectl 配置 localectl 是 systemd 提供的键盘与区域设置工具，可以直接写入 X11 的键盘配置文件。 常用命令如下： 若需要指定键盘模型（例如日本 106/109 键盘），可以使用： 配置完成后，重启桌面会话即可生效。再次检查： 应显示： 手动编辑 X11 配置文件 如果 localectl 不工作，也可以直接写入配置文件： 创建或修改 /etc/X11/xorg.conf.d/00-keyboard.conf： 保存后，重启桌面环境使其生效。 总结 当 Linux 桌面应用出现键盘布局与系统不一致的情况，首先应检查 localectl status 是否显示了正确的 …

在进行服务器管理时，SSH (Secure Shell) 配置文件是非常重要的一部分，它决定了远程连接的安全性和可访问性。本篇文章将详细解析一个典型的 sshd_config 配置文件，旨在帮助管理员了解如何优化 SSH 配置，以提升服务器的安全性。 基础配置 # Include external configuration filesInclude /etc/ssh/sshd_config.d/*.conf 该行指示 SSH 服务使用 /etc/ssh/sshd_config.d/ 目录下的其他配置文件。这种方式有助于分离配置，便于管理和更新。 端口与网络配置 #Port 22#AddressFamily any#ListenAddress 0.0.0.0#ListenAddress :: 主机密钥配置 #HostKey /etc/ssh/ssh_host_rsa_key#HostKey /etc/ssh/ssh_host_ecdsa_key#HostKey /etc/ssh/ssh_host_ed25519_key 这些是 SSH 服务使用的主机密钥文件，分别用于不同的加密算法。根据需要，可以启用对应的密钥。 认证与访问控制 #PermitRootLogin prohibit-password#MaxAuthTries 6#MaxSessions 10#PubkeyAuthentication yes 身份验证与安全选项 KbdInteractiveAuthentication no KbdInteractiveAuthentication 禁用基于键盘交互的认证，这样可以避免一些潜在的安全风险。 PAM（可插拔认证模块）支持 UsePAM yes 启用 PAM …

客户端机器生成公私密钥对 ssh-keygen -t rsa 上传id_rsa.pub到服务器，并将其中内容追加到authorized_keys文件中 然后设置服务器端sshd，更改后 PasswordAuthentication no PubkeyAuthentication yes 重启服务器端ssh服务即可

客户端需要安装openssh-client，服务器需要安装openssh-server，一般情况下默认都是安装好的。 服务器端设置：/etc/ssh/sshd_config中，修改这一行，修改后是这样的： X11Forwarding yes 客户端设置：/etc/ssh/ssh_config中，修改三行，修改后如下： ForwardAgent yes ForwardX11 yes ForwardX11Trusted yes 修改完配置文件，在客户端终端执行 xhost + server_IP ssh -X root@server_IP export DISPLAY=client_IP:0.0 接着在客户端执行图形程序，图形界面便会转发过来了。 即便是服务器没有安装图形界面，只要安装了带有图形界面的程序，就可以进行转发，比如在服务器上安装Firefox，在客户端执行firefox，本地就会打开浏览器窗口。

先切换为root用户 sudo -s 然后运行SSH-KEY命令生成密钥，密钥文件会保存在Root用户目录下，使用时直接读取 sshkey-gen -t rsa 最后把公钥文件上传到服务器，以进行登录时认证使用 sftp user@server_ip put /root/.ssh/id_rsa.pub exit ssh user@server_ip cat /home/user/id_rsa.pub >> /home/user/.ssh/authorized_keys exit 之后再登录服务器即可自动连到到服务器 原因：用户登录的情况下，使用SSH-key只会读取当前用户个人的密钥，而rc.local是以root用户身份运行的，所以需要在root用户目录下创建密钥，否则查看进程会看到认证失败的提示，这个方法主要用在端口开机自动映射的情况下。