linux远程ssh连接不上？

那天半夜被吵醒，服务器突然无法连接，ping也卡住了。
当我登录后端时，发现SSH直接没有响应，系统提示服务已停止。
我赶紧以救援模式启动，发现sshd配置文件的权限被更改了，权限设置为7 7 7 ，导致服务启动时就杀掉了。

我记得上次有一个运维小哥给我演示过这个。
他在机房放置了一块小黑板，上面画着一棵权限树。
他一边擦拭一边说道：“你看，/etc/ssh/目录的所有者必须是root，其他用户不能对其进行写入，否则sshd一读取配置就会崩溃。
” 我当时就笑他，说都十年了，还有人用这种老把戏。
事实证明，这一招还真管用。
将权限改回6 4 4 并重启后，半夜服务器又恢复了。

等等，我突然想到，使用SELinux的系统其实更牛逼。
上次我在 AWS 上升级 RHEL 服务器时，SELinux 锁定了 sshd 权限。
我花了三个小时查看 /var/log/audit/audit.log 来查找规则冲突，最后不得不在启动之前使用audit2 allow 生成新策略。
现在想来，如果我备份了/etc/selinux/config，我就不会那么疯狂了。

现在的系统都配备了防火墙，有时甚至连端口都改变了。
我记得曾经部署在阿里云上。
客户坚称2 2 端口被占用，结果他把安全组规则改成了4 4 3 当我远程向他展示如何更改/etc/ssh/sshd_config的2 2 端口后，他居然在视频的另一端说：“你怎么知道我改了端口？” 我说：“因为日志都是‘连接被...端口 4 4 3 拒绝’。
”
备份配置文件，确实需要养成一个习惯。
上次帮隔壁公司恢复系统，他们备份的是/etc/shadow，而不是sshd_config。
结果密码系统恢复了，但是SSH还是无法启动。
我连夜给他们写了一个shell脚本，每天用cron来同步这两个文件。
第二天运维小姑娘对我说：“师傅，以后我们在改配置之前先运行你的脚本。
” 我说：“这个东西是我十年前写的，当时是师父教我的。
”
现在想想，其实最好的办法就是使用免密码登录跳板。
上次在腾讯云做实验环境的时候，主服务器的ssh配置崩溃了。
于是，我通过腾讯云管理控制台ssh到另一台备份机，然后切换回主服务器。
运维总监在一旁说道：“年轻人，你做的太酷了。
” 我说：“主任，您在华为做网络工作的时候，经常使用这种很酷的操作吗？” 他愣了三秒，突然大笑起来。

话虽如此，为什么这些服务器必须有如此复杂的权限呢？ 你害怕有人改变配置吗？ 还是当时设计系统的人把最简单的部分留给了自己？ 突然我想到了一个笑话：一个黑客进入了系统，把所有权限都改为7 7 7 ，然后跳出来说：“看，我找到了你系统中最糟糕的部分。
” 系统管理员回应：“那你至少得改密码啊！” 黑客挠了挠头：“我忘了怎么改了……”
现在半夜崩溃的服务器已经恢复了，我导出日志，发现最后的错误是sshd: no such file or directory。
它应该是文件权限更改得太彻底了。
我得赶快给运维总监发邮件，建议将sshd_config添加到visudo的默认模板中。
他回答道：“等你教我如何使用Python脚本编写自动化部署。
” 我突然觉得，也许这就是运维人的宿命，总是在救火和制定灭火方案之间来回奔走。

sftp用户目录授权777后登录不上

哦，让我告诉你我陷入的陷阱。
前年，我在上海帮朋友搭建服务器。
朋友添加了一个新的SFTP用户，并授予他的主目录7 7 7 权限。
结果他无法登录。

我当时就一头雾水。
查了资料发现SFTP用户的主目录设置为7 7 7 ，肯定是不行的。
想一想，任何人都可以更改这个目录，任何人都可以删除它，这不是很明显会破坏系统吗？后来发现这个和chroot环境有关。
如果使用 Chroot 将用户锁定到某个目录中，则该目录之上的所有父目录以及所有可访问的目录都必须是 root 才能管理它们。
这些目录不能有组权限，否则不安全。
最大是7 5 5 ，如果给7 7 7 肯定不行。

我很快将目录权限更改回 7 5 5 并使用 chmod 7 5 5 /path/to/directory。
然后我更改了所有原始目录并使用 chown root:root /path/to/directory 来确保所有原始目录都是根目录。
然后我查看了 sshd_config 并确保 ChrootDirectory 设置正确。
最后，我检查了/var/log/auth.log，并确认有错误消息。
更改这些权限并重新启动 SSH 服务后，就可以登录了。

记住，处理这些权限时要小心。
所以7 7 7 ，这是非常危险的。
去年，另一位客户的权限设置不正确。
结果远程执行命令，整个系统几乎丢失。
所以，如果你不确定的话，不要盲目改变。
问问像我这样掉进陷阱的人。

linux远程不了怎么办

说白了，如果Linux无法远程连接SSH，很可能是因为该服务没有启用、防火墙阻止了或者配置不正确。

首先最重要的是SSH服务启动。
使用systemctl status sshd查看一下。
如果它停止，请使用 systemctl start sshd 启动它。
去年，我们在运行该项目时，曾因计划任务禁用了 SSH，迫使所有人远程登录。
还有一点就是防火墙必须允许2 2 端口。
对于Ubuntu，使用ufw允许ssh即可。
对于CentOS，您需要使用firewall-cmd --permanent --add-service=ssh 添加永久规则，然后使用firewall-cmd --reload。
很多人都没有注意到这一点，以为安装了OpenSSH就万事大吉了。

一开始我以为网络问题是最常见的问题，后来发现不对。
现在首先检查防火墙的概率可以代表6 0%。
还有另一个关键细节。
例如，如果SELinux失败，它可能会直接拒绝连接。
暂时用setenforce 0测试一下。
如果这不起作用，请更改配置。
说实话，这很令人困惑。

检查 auth.log 时，不要只查看时间戳，还要查找“密码失败”或“权限被拒绝”等关键字。
去年我们遇到了由于sshd_config中的PasswordAuthentication no导致的全局拒绝。

建议从 systemctl status sshd 和 ufw status/firewall-cmd --list-all 开始。
该组合的捕获率最低。