Linux实现ssh双因子登陆,with Google Authenticator

之前听别人说,用了XX家的云,安装一个手机APP,每次登陆需要先验证动态密码,再输入密码,安全性大大提高,实现了传说中的双因子登陆,当时觉得好洋气.
因为之前关注的角度不同,我更多的是从登陆统计以及报警来观察,毕竟让你直接登陆的堡垒机或者跳板机并不多,是我太out,听说过双因子登陆却一直没有去行动,于是心血来潮详细百度谷歌了一些文章,更多的都是通过添加第三方模块增加二次验证,于是几个较为出名的就来了:谷歌认证google-authenticator,freeotp,洋葱令牌,对比了一下名字,发现还是谷歌的名头让我比较有安全感,同时了解了一下洋葱令牌,国产货,号称可以保存在云上,不用担心换手机的后遗症,下面就讲讲我的安装,相关的文档其实已经挺多了,步骤也挺简单,拾人牙慧吧

首先是环境准备,我是常年自备虚拟机:2台centos6.7最小化安装

1.安装方式,centos6的环境下
1) epel源自带google-authenticator,可以直接yum安装,就是这么简单粗暴

rpm -ivh https://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm yum install google-authenticator

2) github上直接拉最新源码安装,centos7下会提示缺少m4目录,先安装好依赖环境

yum install git wget make gcc pam-devel yum install automake autoconf libtool libpng-devel qrencode -y

git clone https://code.google.com/p/google-authenticator/ cd google-authenticator/libpam/
./bootstrap.sh
./configure
make
make install

2.生成密钥以及一次性密钥,如果是按照以上方式安装了qrencode,会在执行程序时生成一张大大的二维码图,手机扫一扫即可,也可以手动输入验证码,还有另外一种方式直接打开生成的url地址,里边是一张同样的二维码图,只不过你需要翻墙才能看,效果是这样的




1) google-authenticator,会在你的家目录生成一个.google_authenticator 文件
同时会问询一些机制和方式,如果看不懂的话一路yes也是好的

Do you want authentication tokens to be time-based

是否基于时间生成密码,这种认证方式分为HOPT和TOPT,一个是基于计数器来计算,一个是通过时间来计算,国内大多是基于TOPT,然而已经有云提供这种二次验证了,表示没用过,不心动...

2)

Do you want me to update your "/root/.google_authenticator" file (y/n)

是否将更新到/root/.google_authenticator文件中,在执行到这一步的时候往上看,会显示这些内容:

https://www.google.com/chart?chs=200x200&chld=M|0&cht=qr&chl=otpauth://totp/root@Base%3Fsecret%3DJ2UDL6O3DT7QVZA3%26issuer%3DBase
Your new secret key is: J2UDL6O3DT7QVZA3
Your verification code is 312253
Your emergency scratch codes are:
37117552
96751003
22043179
27575526
80187267

如果包没有漏装的话还会显示出一个特大号的二维码图,打开提供的url地址也是可以的,但是你懂的
似乎verification code is 312253这个是手动输入手机APP的验证码,相当于银行U盾和你的手机绑定,这个和secret key都没测过,直接通过二维码扫描就可以了,如果手动的话还需要输入用户和主机信息,下面一串数字是紧急验证码,每个只能用一次,比如手机没带

3)

Do you want to disallow multiple uses of the same authentication
token? This restricts you to one login about every 30s, but it increases your chances to notice or even prevent man-in-the-middle attacks

是否多个相同的令牌限制每30秒只能登陆一个,这样会更安全

4)

By default, tokens are good for 30 seconds and in order to compensate for
possible time-skew between the client and the server, we allow an extra
token before and after the current time. If you experience problems with poor
time synchronization, you can increase the window from its default
size of 1:30min to about 4min. Do you want to do so (y/n)

如果你的时间同步不靠谱,可以增加窗口1分半到4分钟...意思应该是增加容错率吧,有效时间变相增大,不再是默认的30秒,友情提示,一定要先做好时间同步,某些应用依赖TOPT的,当时间错误以后会有漏洞产生

5)

If the computer that you are logging into isn't hardened against brute-force
login attempts, you can enable rate-limiting for the authentication module.
By default, this limits attackers to no more than 3 login attempts every 30s.

30秒内只能登陆3次

3.既然服务器端已经完成了google认证的配置,手机上来一发app对接上吧,我的是依旧坚挺的5s,苹果用户之间登陆AppStore搜索google authenticator,界面简单粗暴,点击身份验证器,然后选择二维码扫描即可,给大家看看这个界面
提示:相信从APP界面中能够看出不同用户和主机的密码是不同的,这意味着你必须在服务器上的每个用户都执行一遍google-authenticator,生成独立的.google-authenticator文件,以及产生独立的紧急密码



安卓客户端没有测试,谷歌商店肯定是有的,其余应用商店大家可以自己找找,同样简单粗暴,扫描添加完成后会每30秒刷新一次6位数密码,是不是和各种U盾,XX宝的动态密码一毛一样了,如果有空的话还会尝试一下洋葱令牌,不是因为功能强大,而是因为它支持刷脸等各种姿势...

4.手机和服务器对接上了,最后就是服务器上应用谷歌的验证模块了
1)

vim /etc/pam.d/sshd

在第一行添加

auth       required     pam_google_authenticator.so

测试发现一定要在password-auth前面,就是说必须先验证动态密码,再验证用户密码,顺序不能调换,调用google的这个库文件才能启用验证
2)

vim /etc/ssh/sshd_config
ChallengeResponseAuthentication yes

#把NO禁用,改为YES,开启质疑--应答认证,不然光是开启了pam模块的google验证,在登陆时依然只是只询问用户密码,但会返回Permission denied, please try again.必须两个文件同时修改,只关闭pam验证时可以正常登陆

5.最后一下,然后浪起来

service sshd reload

最后附上github地址:https://github.com/google/google-authenticator
新的测试环境一定要关闭selinux,不要问我是怎么知道的,如果对详细算法有兴趣的,可以谷歌一下,github上貌似也有

补充一下,假如各方面都配置好了,但是仍然不能有效工作的,找到你源码中的pam_google_authenticator.so文件,拷贝到/lib64/security路径中,有效的登陆界面应该是这样子




再次补充,重要,上生产环境前需要注意,百度和google的文章中也并未提起:
每个用户需要单独运行程序产生个人文件,独立的密码,有点类似于mysql的赋权,同时基于用户名和主机名的认证

当启用密钥认证的时候,动态密码验证无法生效

经测试,sshd_config文件中即使关闭了密码验证,PAM模块pam_google_authenticator.so生效后仍然可以先验证动态密码,再输入用户密码
在配置文件中关闭密码认证后,强制默认为优先验证动态密码,再验证用户密码

当启用密钥之后,多个用户中,有密钥认证的依然会走密钥认证这种方式,而删除或者没有密钥认证的用户则会走动态密码+用户密码的方式,彼此没有影响和冲突