Azure上的虚拟机重启后无法使用SSH

故障描述: 在处理故障时,由于配置些服务后要对Azure虚拟机进行重启,重启后发现无法使用ssh连接

故障处理过程

1. 重启中后,使用xshell连接时,socket就马上closed,对它做ping测试再现网络是正常的

 

2.同事建议向Azure的后提供技术支持,以是拨打客户电话拨打 400-089-0365 或 010-84563652 获取支持,联系到后台技术人员后,先提供相应的账户信息,工程师说能够提供console给我们进行连接,工程师发邮件来,需要我方先确认同意以上操作条款,然后使用teamview连接到对方的机子操作自己的虚拟机

 

3.使用账号密码登陆就报错

Permission denied

 

4.尝试进入用户模式进行修改密码和其他操作(centos7.4单用户模式操作,与centos6的操作有不一样)

 

重启时,需要touch   /.autorelabel,如果要使用selinux

 

5.尝试新密码时,还是继续报权限问题,以是继续在用户模式下进行排查故障,查看安全相关的日志/var/log/secure，发现如下问题

 

6.对/etc/security/limits.conf参数修改(这里的操作，实际填写有点过大,最后修改下尝试不行,最后注释掉)
linux 修改用户可打开的文件数特别大的方法//ssh登陆pam_limits(crond:session): Could not set limit for ‘nofile’: Operation not permitted的处理方法
分析：若需要允许用户使用很大的文件资源需要先修改内核的文件资源数限制,修改用户可打开的文件数一般直接修改limits.conf的nofile,即可，但是如果将这个值修改为上百万很有可能导致ssh无法登陆、系统异常,因为很可能用户可打开的文件数量超过了内核可打开的文件数量

正确的修改方法如下：

先修改内核可打开文件数量，再修改用户可打开文件数量
内核限制数的具体位置是：
/proc/sys/fs/file-max –系统级别所有进程可打开的文件数
/proc/sys/fs/nr_open –定义了file-max允许被修改的最大值，file-max不可以超过该值

修改/etc/sysctl.conf增加：
fs.file-max =***
fs.nr_open = ***

即可修改内核的配置

修改完成后，再修改 /etc/security/limits.conf

　　* soft nofile ***
　　* hard nofile ***

然后重启系统即可

 

7.检查发现selinux启动,尝试把enforcing修改成disabled,重启后可以正常连接

[root@test ~]# grep SELINUX= /etc/selinux/config 
# SELINUX= can take one of these three values:
SELINUX=disabled     ##修改停止selinux