Linux远程管理基础方法_安全连接实践解析【指导】

SSH 连接失败应先检查 sshd 服务状态和 22 端口监听，再排查密钥权限、配置语法及防火墙 / 安全组放行；禁用密码登录前须确保密钥 100% 可用，并保留备用通道。

SSH 连接失败：检查 sshd 服务状态和 端口 监听

远程连不上，第一反应不是改密钥，而是确认服务本身是否在跑。很多新手直接跳过这步，对着 Connection refused 反复重试密码，其实 sshd 根本没启动。

• 用systemctl status sshd（或systemctl status ssh，取决于发行版）看服务是否active (running)
• 执行 sudo ss -tlnp | grep :22 确认 22 端口是否被 sshd 监听；若输出为空，说明未监听，可能配置了非标端口或 ListenAddress 绑定了特定 IP
• /etc/ssh/sshd_config中检查 Port、ListenAddress、PermitRootLogin 三行——尤其当修改过配置后，必须 sudo systemctl restart sshd 才生效，reload 不一定触发重读

密钥登录配不成功：权限和路径是硬门槛

密钥方式看似安全，但 ~/.ssh/authorized_keys 文件权限不对，sshd会直接拒绝，且不报明确错误，只显示Permission denied (publickey)。

• 客户端私钥 id_rsa 必须为600（chmod 600 ~/.ssh/id_rsa），否则 OpenSSH 会拒绝加载
• 服务端 ~/.ssh 目录权限不能大于 700，authorized_keys 不能大于600；常见误操作是用chmod -R 755 ~/.ssh，导致登录失败
• 确保 sshd_config 中PubkeyAuthentication yes且 AuthorizedKeysFile .ssh/authorized_keys 未被注释或改写
• 调试时加 -v 参数：运行 ssh -v user@host，看日志里是否出现Offering public key 和Server accepts key

禁用密码登录前，务必验证密钥已 100% 可用

把 PasswordAuthentication no 一加 就锁死自己，是远程管理最典型的“手滑事故”。这不是理论风险，是高频真实场景。

• 不要在单次 SSH 会话中连续执行：先开两个终端，一个保持密码登录的备用通道，另一个测试密钥登录成功后，再改配置重启sshd
• 改完 sshd_config 后，用 sudo sshd -t 校验语法，避免因拼写错误（如 noo）导致systemctl restart sshd 失败，服务中断
• 生产环境建议保留一个具有 sudo 权限的密码用户作为应急账号，哪怕主账号全走密钥
• 若已锁死，只能通过 VPS 控制台、物理机本地终端或云平台的 Web Console 介入修复

非 22 端口与 防火墙 协同放行

改端口不是为了“隐蔽”，而是减少暴力扫描噪音。但只改 sshd_config 里的Port，不碰防火墙，等于开门却堵窗。

• CentOS/RHEL 8+ 默认用firewalld：sudo firewall-cmd --permanent --add-port=2222/tcp（替换成你的端口），再firewall-cmd --reload
• Ubuntu/Debian 常用 ufw：sudo ufw allow 2222/tcp，确认sudo ufw status verbose 中该端口状态为ALLOW IN
• 若用 iptables，注意规则顺序——INPUT 链中 ACCEPT 规则需在 DROP 之前；可临时用 sudo iptables -I INPUT -p tcp --dport 2222 -j ACCEPT 插入最前
• 云服务 器（如 阿里云、AWS）还需在安全组里额外放行对应端口，这个常被忽略

ssh -i ~/.ssh/mykey.pem -p 2222 admin@192.168.1.100

密钥路径、端口、用户、IP 缺一不可；少一个 -i 或写错 -p，连接行为就彻底变成密码尝试。实际运维中，这些参数往往固化在~/.ssh/config 里，但首次调试一定手动敲全，避免 配置文件 掩盖真实问题。