因为错误配置shell导致登录时报错 “Login incorrect“

起因

这里只给自己提个醒，想看解决方法的直接跳过。
作为一个程序员，shell环境很重要，于是乎在公司的一台专用服务器上装了fish交互式shell，相比于bash它有很多优点。但是美中不足的是，它不完全兼容原shell的语法，导致source /etc/profile会报错。于是在网上找了这篇帖子，里面解决步骤如下：

ou can use bash to parse /etc/profile and ~/.profile, and then start fish.

Create /usr/local/bin/fishlogin with contents

 #!/bin/bash -l
 exec -l fish "$@"
Make it executable

 sudo chmod a+rx /usr/local/bin/fishlogin
Check that it works by running fishlogin and checking that you end up in a Fish shell. Press Control+D to exit the Fish shell.

Add it to /etc/shells

 echo /usr/local/bin/fishlogin | sudo tee -a /etc/shells
Set it as your default shell.

Under Linux:

 sudo usermod -s /usr/local/bin/fishlogin $USER
Under macOS:

 chsh -s /usr/local/bin/fishlogin $USER

具体原因不知道，只是执行完这一顿操作后，ssh和console登录再也登录不上了，只会提示"Login incorrect"。这台服务器上的环境我部署了两天，如果登录不是就GG了，简直汗流浃背。

故障排除手段

遇到这种问题，只有以下几种解决方法：

1. 在一个已经连接上的ssh终端操作，进行登录修复
2. 进入“救援模式”或者“恢复模式”，进行登录修复
3. 拆掉原主机的系统盘，在另一台linux上进行登录修复

我联系了服务器厂商，他们帮忙进入“救援模式”，可以得到一个类似busybox的终端，可以修改原系统盘的一切文件。

解决方法

第一次尝试

由于实际只有这两行命令对系统有影响：

 echo /usr/local/bin/fishlogin | sudo tee -a /etc/shells
 sudo usermod -s /usr/local/bin/fishlogin $USER

我立即进行了文件还原：

1. 首先编辑/etc/passwd，将原用户的登录shell还原为/bin/bash；

root:x:0:0:root:/root:/bin/bash

2. 同时还发现，居然原帖子的命令前面有空格，不确定有没有影响，也将空格去除了。

(空格)#!/bin/bash -l
(空格)exec -l fish "$@"

他丫丫的，故意藏bug呢，命令前的空格被我直接复制到文件中了。
3. 在/etc/shells文件中，删除最后一行/usr/local/bin/fishlogin

想着上次执行的指令就影响了启动shell，现在已经还原为bash，就直接重启了。
结果还是登录不了！！！

第二次尝试

依旧重启到救援模式，由于救援还是厂家帮我进入的，不能老是叫他帮我弄，这次必须得谨慎，确保万无一失才能重启到原系统。
先切换到原系统目录，这一步的目的是获取你原系统的命令和环境，在救援模式执行如passwd，vim /etc/passwd时就和在原系统操作是一样的作用，操作的都是原系统的文件：

# 先挂载你的原系统盘
cd {挂载了原系统的文件路径}
chroot `pwd`

1. 由于没有思路，第一件事就是查日志，GPT给出了以下几个关于登录的日志：

# 认证相关的日志文件，它记录了系统认证过程的详细信息，包括登录尝试、用户登录和注销事件等
tail -f /var/log/auth.log
# 与安全相关的日志信息，包括 SSH 登录尝试、密码登录尝试、邮件传递、X 服务器访问等。
tail -f /var/log/secure
# 文件记录了所有成功的登录、注销和系统启动、关机事件
last -f /var/log/wtmp
# 文件记录了所有失败的登录尝试
last -f /var/log/btmp
# 系统审计日志，它记录了系统活动的详细信息，包括用户登录尝试、文件访问、系统配置更改等
tail -f -f /var/log/audit/audit.log

最后在/var/log/secure看到有一些值得关注的报错

Apr 28 16:19:23 localhost login: pam_tally2(login:auth): /var/log/tallylog is either world writable or not a normal file
Apr 28 16:19:23 localhost login: FAILED LOGIN 1 FROM ttyAMA0 FOR root, Authentication failure
Apr 28 16:19:28 localhost login: pam_tally2(login:auth): /var/log/tallylog is either world writable or not a normal file

用vi打开该文件/var/log/tallylog ，显示是乱码，有可能是文件损坏了，也可能它是二进制文件？在网上搜索了一下，执行了以下操作：

# 清空文件，反正只是日志而已
echo > /var/log/tallylog 
# 还原正常权限
chmod 600 /var/log/tallylog 

登录失败次数清零，这一步是解除被锁定的用户root

[Service not authorized][root@localhost ~]# pam_tally2 -u root
登入者          失败次数 最近日期    时间  来自于
root                0
# 其实造成登录失败的原因因该不是用户被锁定了，但是还是操作一下吧
# 这里重置你自己系统上的用户
pam_tally2 --user root --reset

到此结束了吗

并没有，前面说的是厂家帮忙进入的救援模式，必须珍惜这次机会，所以还是做了如下保证：

# 创建多个备用的用户，万一有一个能登录上呢
useradd -g root test
useradd -g test2

创建用户后，检查/etc/passwd，看原创建的用户的用户目录是否存在，不存在则创建。

到此，能做的基本都做了，sshd在救援模式是启动不了的，所以到此只能重启了。好在root用户终于可以正常登录了，创建的几个备用用户没有用到。

总结

1. 很有可能是/var/log/tallylog 文件出问题导致的，将内容清空并重新赋予600权限；
2. 复制别人的命令，一定要仔细检查，在文件编辑时前面多个空格很可能出问题；
3. 修改重要系统配置之前，多连接几个已经root登录的shell，防止后续修改导致系统登录不上，手足无措。配置修改后，重新登录，以确保登录没有问题，如有问题，用之前的登录的shell进行还原；