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一加就锁死自己，是远程管理最典型的“手滑事故”。这不是理论风险，是高频真实场景。

word-document-organizer

智能整理Word文档，自动排版、生成目录、统一样式，支持学术/商务/极简模板。

下载

• 不要在单次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）还需在安全组里额外放行对应端口，这个常被忽略

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