背景：用户的一台生产机器在许久之前就出现了SSH无法登录操作系统(Ubuntu 22.04系统)的现象，但由于生产环境是有多台机器在支撑业务的，所以坏一台也不会影响业务，但用户近期将此问题反馈了过来想让帮忙解决掉此问题，但询问操作系统内做了哪些操作，给的答复都是很模糊，可以说完全不知道...于是只能在系统内自行排错了
首先我们在控制台窗口输入账号密码后，发现登录不上，初步怀疑可能是用户给的账号密码有误导致的，于是想通过进入救援模式进行密码重置后再次登录验证，但在进入救援模式过程中，弹出让其输入root密码相关提示，
此时我们输入密码后，发现能够正常登录，即验证了账号密码的准确性，排除了密码错误的可能
这里省略了一部分截图，原因在于问题排错时没能及时截图保留，在救援模式下能正常登录操作系统后检查了iptables规则、防火墙、hosts.deny、hosts.allow、/etc/passwd及/etc/shadow 等配置文件的权限，发现无异常，于是在救援模式下创建了一个测试账号用于登录验证，而后进行系统重启，在控制台界面下依然无法通过root以及测试账号进行登录，但发现测试登录的控制台都是tty1，于是通过切换tty进行登录验证，依旧不可行，所以判断为非账号问题及控制台问题，即可能是其他限制导致的。
---------
再次重启操作系统进入救援模式，此时我们检查了/var/log/auth.log 的日志，发现有相关线索，如下图所示
在auth.log日志中能看到前面测试登录切换了不同的tty，但还是无法正常登录，但关键线索在于 /lib/security/pam_tally2.so 模块未被找到，
于是查看common-auth 配置文件，发现确实有启用该模块，将其注释后进行重启登录验证，依旧无法正常登录，于是再次重启操作系统进入救援模式，在 /etc/pam.d/目录下执行了 grep -rn "pam_tally2.so" 对当前目录下的所有文件进行筛查，发现名为 login的配置文件也启用了pam_tally2.so模块，于是我们再注释掉后进行系统重启登录，此时问题得到解决。
小结1： 连控制台都无法正常登录的原因在于用户在操作系统内启用了一个系统内并不存在的模块，而pam_tally2.so模块是与时间限制相关的，可以控制用户在某些时间段内能有访问权限，但此模块并不存在于操作系统上，所以无法正常验证通过，即在auth.log抛出异常日志并拒绝所有用户的登录访问请求。
无法登录的问题解决完后，在启动ssh服务的时候发现ssh服务无法正常启动，报错信息为
sshd -T 命令检查配置文件正确性，发现提示GLIBC_2.36依赖找不到，庆幸机器能够上网的情况下，进行了apt源更新，执行了 apt update，而后尝试安装glibc_2.36，但无法正常安装，提示缺少某些依赖啥的（忘记保留截图），接着想通过重装openssh-server尝试能否自动解决依赖包问题时，又遇到以下报错
大概意思是告知我们，该软件包无法被安装，建议我们执行 apt --fix-broken install 来解决依赖包的问题（与一开始想安装glibc_2.36的报错类似）
我们根据建议执行，发现自动剔除了openssh-server服务后即可正常使用apt命令安装openssh-server了，即问题解决
小结2：根据处理过程来看，可能用户是通过dpkg方式安装ssh deb包，但该方式并不会自动解决依赖包关系，于是还需通过apt修复依赖包关系后再安装openssh-server
标签：处理过程,操作系统,登录,apt,账密,无法,控制台,pam From： https://www.cnblogs.com/Ky150/p/18334304