Die Linux-Remote-Anmeldung kann nicht durchgeführt werden(Fülle die Grube)

近日, 某研发部门领导焦急反馈 他们的一台测试机无法连接, 很急, 多位同事都未处理好,准备放弃.

该服务器系统为CentOS6, 是VMware Esxi的一台虚拟机.

用vSphere连接到Vcenter后,找到该虚拟机.进入控制台发现该虚拟机处于开启且未登录状态.

根据研发提供的root帐号和密码, 多次尝试登录, 一直失败.

当时怀疑研发记错了密码, 或者被其他人改了密码.

随后,进入单用户模式重置了root密码, 很简单的123456. 重启后root仍然无法登录.

我怀疑是自己重置密码方式有问题, 重试验多次均以失败告终.

也就是: 单用户模式密码root密码提示成功, 但正常启动后root却登录失败.

非常郁闷的情况: 于是再次进入单用户模式, 用root创建了一个普通用户,并指定密码.

正常启动后,普通用户奇迹般的登录进去.

接着使用su – root 切换用户身份.发生了权限错误.

使用sudo 命令,提示普通用户没有在sudoers文件中(随后重新进入单用户模式,existieren

sudoers中增加了普通用户)

再次使用sudo命令, 切换仍然失败,如下图:

经过上述提示, 发现是权限问题,于是看看 sudo.conf文件状态

不可思议吧, 777权限. 于是改成了默认的640权限. sudoers.so也是777权限,改成了默认的 755权限.

单用户修改完成后, 正常模式下用普通用户登录,然后顺利通过使用sudo和su命令.

且成功切换到root.

本以为万事大吉了, xshell远程连接搞起, 仍然连接失败. 但这时IP地址可以ping通.

进入vmware控制台一看. 我靠, sshd服务没启. 顺带启动一下, 惊喜不断

查看ssh_host_rsa_key和ssh_host_dsa_key 也都是777权限.

不想说啥了, 改成正常权限sshd服务即可正常启动.

真相清楚了. 一定有人这么干过 chmod 777 * , 下图更惊喜.

in diesem Moment, 能做的就是 1. 将重要的目录和文件权限恢复正常 2. 警示该部门同事严格执行操作, 不要想当然

以为给777就方便了. 3.加强linux安全学习.

经过处理, 至此远程成功连接, 业务恢复运行.

zu guter Letzt: 对服务器操作要心存敬畏感, 不做没有把握的操作, 否则出现事故 ,

花费大量精力和金钱 能不能挽回损失还两说呢.