TG咨询在云主机、办公室 Linux 服务器或异地运维环境中，SSH远程登录配置往往决定了系统管理入口是否暴露。很多人首先想到把默认的 22 端口改成其他数字，但这只能减少一部分自动化扫描，不能替代身份认证和访问控制。更可靠的顺序是：先明确谁能连接，再限制从哪里连接，最后决定使用什么认证方式。
先限制网络入口，再调整监听端口
SSH 服务通常由 OpenSSH 提供，配置文件常见位置是 /etc/ssh/sshd_config。公网服务器不宜让整个互联网直接访问 SSH 端口。若运维人员拥有固定办公出口 IP，可以在云平台安全组和主机防火墙中同时设置来源白名单；若办公网络地址经常变化，则应考虑通过 VPN 或跳板机进入内网，而不是反复扩大放行范围。
端口限制的实际作用
修改 Port 22 为其他端口，例如 2222，能够避开大量只扫描默认端口的低质量请求，但不能阻止有针对性的端口探测。真正关键的是防火墙规则：只允许指定网段访问 SSH，其余来源默认拒绝。云安全组、nftables 或 ufw 可能同时存在，修改前应确认实际生效的防护层，避免只改一处造成误判。
如果必须修改端口，应先保留当前 SSH 会话，打开第二个终端验证新端口，确认成功后再关闭旧端口。以 Ubuntu 24.04 为例，调整配置后可使用“sudo sshd -t”检查语法，再通过“sudo systemctl reload ssh”重新加载服务。不同发行版的服务名称可能是 ssh 或 sshd，执行前应以本机实际服务名为准。
登录权限要按角色收紧
SSH远程登录配置的第二个重点是控制可登录账户。不要让所有本地账户都能尝试远程登录，也不要把日常运维全部集中在 root 账户上。更适合的做法是创建个人账户，使用 sudo 执行必要的管理操作，并在 sshd_config 中设置 AllowUsers 或 AllowGroups，只放行明确的用户或用户组。
高权限账户与密码登录
可以设置“PermitRootLogin no”，禁止 root 直接通过 SSH 登录。这样即使某个普通账户凭据泄露，攻击者也不能直接以 root 身份进入系统；管理员仍需通过 sudo 完成授权操作。若业务确实需要 root 远程登录，应至少限制来源地址并采用密钥认证，但这通常不如个人账户审计清晰。
对于公网主机，建议在确认公钥认证可用后设置“PasswordAuthentication no”。关闭密码登录前，必须先在新终端用私钥成功登录，并确认私钥文件、权限和备用管理员账户都能正常使用。若服务器仍有旧系统、自动化任务或供应商工具依赖密码认证，则应先评估迁移计划，不能直接切换。
公钥认证如何落地
公钥认证由客户端私钥和服务器端公钥配对完成。常用密钥类型是 Ed25519，创建时可使用“ssh-keygen -t ed25519”。私钥只应保存在受控设备上，建议设置本地口令；公钥则写入服务器用户家目录下的 .ssh/authorized_keys 文件。
- 在管理员控制的电脑上生成 Ed25519 密钥，并为私钥设置口令。
- 将公钥追加到目标账户的 authorized_keys，而不是覆盖已有内容。
- 检查 .ssh 目录通常应为用户可读写，authorized_keys 不应允许其他普通用户修改。
- 保持旧会话不动，使用新终端指定私钥登录，确认 sudo、文件权限和必要运维命令都可用。
- 确认至少有一种可靠的恢复路径后，再关闭密码登录或删除不再使用的公钥。
多人共用同一把私钥会削弱审计和撤销能力。更好的方式是每名管理员使用独立密钥，离职或设备丢失时只删除对应公钥。密钥轮换周期应结合组织制度和风险等级安排，关键环境可按季度或在人员、设备发生变化时立即更换。
防火墙、暴力尝试与审计
端口限制不能代替账户控制，账户控制也不能代替日志审计。可以利用 ufw 或云平台安全组限制来源，再配合 fail2ban 对短时间内重复失败的地址进行临时封禁。fail2ban 的封禁时间、最大失败次数和日志路径需要结合发行版、网络环境及误报情况调整，不能照搬一组固定数值。
登录后应定期查看认证日志。例如 Debian 12 常见日志位置包括 /var/log/auth.log，部分系统也可通过 journalctl 查询 ssh 服务记录。重点关注异常时间段、陌生来源地址、连续失败、成功登录后的权限提升和新建账户。若服务器由集中式日志平台管理，还应确认 SSH 登录事件确实被转发，避免主机日志被删除后无法追溯。
一套较稳妥的变更顺序
- 盘点现有账户、登录来源、自动化任务和应急入口。
- 先配置云安全组或主机防火墙，只允许必要来源访问当前 SSH 端口。
- 为个人账户部署公钥，验证新会话和 sudo 权限。
- 禁止 root 直接登录，并用 AllowUsers 或 AllowGroups 缩小账户范围。
- 在确认兼容性后关闭密码认证；如需改端口，先验证新端口再移除旧端口规则。
- 执行配置语法检查、重新加载服务，并保留现有会话观察日志。
每次只改变一类控制项更容易定位问题。若一次同时改端口、防火墙、账户和认证方式，出现无法登录时很难判断原因。对关键服务器，变更前应准备云控制台、串口或现场控制台等带外恢复方式，并记录原配置和回滚步骤。
常见问题
只修改 SSH 端口就安全吗？
不安全。改端口只能减少默认端口上的噪声扫描，仍需限制来源、收紧账户并使用公钥认证。
关闭密码登录前必须做什么？
必须在独立终端用私钥成功登录，并确认备用账户或带外控制台可用，避免因密钥错误把自己锁在系统外。
是否应该完全禁止 root？
通常应禁止 root 直接 SSH 登录，改用个人账户加 sudo。特殊场景需保留 root 时，应限制来源并加强审计。
防火墙应该放在云平台还是主机内？
两层都可使用。云安全组适合先挡掉外部来源，主机防火墙提供本机级控制；但要确认规则没有相互冲突。
归根结底，SSH远程登录配置应围绕“谁能连、从哪里连、用什么方式认证、如何追踪”展开。优先限制端口来源和登录权限，再处理端口编号与辅助防护，才能在减少暴露面的同时保留可恢复、可审计的运维路径。
