Linux 运维:SSH 服务的最佳实践

最近又提起了兴趣去折腾 VPS,买好一台新的 VPS 服务器后,第一件事情就是登上去设置环境,当然, 登录必不可少,这也是远程操作一台服务器的先决条件。不过 服务器,默认不是按照最优的方式去配置的。所以,我打算自己总结一下 服务的最佳实践。

禁止 root 用户直接登录服务器

新的 VPS 分配的时候,都是默认设置 root 用户,并且设法把密码发送给管理员知道。root 用户是 系统权限最高的用户,一旦泄漏了,后果不堪设想,黑客可以使用 root 的权限完全控制一台服务器。

比较好的做法是,禁止 root 账户直接登录到服务器上,因为如果允许 root 登录,就可能让黑客通过攻击直接得到 root 的权限。

比较好的实践方式是,设定一个非 root 的账户,用于日常登录使用,需要的时候,使用 sudo 临时取得权限,或在本地 登录到 root 帐号。

上面的代码,在系统里建立了一个新的用户,给这个用户创建一个密码,密码可以用于使用 sudo 命令。

然后使用 gpasswd 将用户加到 wheel 用户组,在 CentOS 上,就可以让用户得到 sodu 权限。 多年来我积累了一套自己使用非常习惯的 shell 配置,也建议读者这么做,可以去看看我的做法 https://github.com/charlestang/env.git 就会明白我在说什么。实现这套配置,环境变量少不了,比如 vim 的配置问题。

你可能会发现,sudo 后面使用 vim 的话,很多高级配置都无法生效。其他的命令也可能有这个问题。产生的原因其实是在一个用户的环境下设置的环境变量,使用 sudo 的时候,就会失去。可以通过代码片段的 visudo 命令,打开配置文件,指定要代入到 sudo 场景下的环境变量。

使用 sudo 会带来很多的不变,但是,作为一个运维人员,还是要养成不使用 root 的好习惯。各种小问题都是可以克服的。

使用基于公钥验证的登录

一般来说,购买一台服务器,新分配的时候都是默认用户名密码登录的,国内的阿里云、腾讯云都有这样的,国外的 Linode,前两天体验的 Vultr 也是。

但是,密码验证这件事情,在密码学里叫 PSK,pre-shared key,预先共享的。也就是至少有两方知道这个密码。而且,在公有云,是云平台设定的第一个密码,所以云平台是知道的。

更安全的方式,是使用非对称加密的方式,也就是基于公钥验证的登录。首先要在本地创建一个公私钥对,然后,把公钥注册到服务器的 authorized_keys 文件里。

插图节选自《HTTPS权威指南》

关于非对称密钥的长度问题,我看到 CentOS 7 的文档里面介绍,默认的 RSA 的长度是 2048 位,文档里认为足够了,而且建议的最短长度是 1024 位。上面的例子里,我特意用了 4096 位,哈哈,希望能用 30 年……插图选自一本技术书籍,内容是2012年,权威机构对密码长度和对抗强度的一个估算。

公钥文件配置在服务器的非 root 用户的 ~/.ssh/authorized_keys 文件里面,内容贴进去就可以了。一般来说,服务器缺省设置,都是支持使用公私钥验证进行登录的。下面是对/etc/ssh/sshd_config的配置;

更换SSH服务的默认端口

SSH 服务的默认端口是 22,这个端口已经是全网皆知的了,也是网络上自动化工具攻击的首要目标,希望自己的服务器安全的话,就首先要把这个端口给更换掉。

推荐使用 10000 号以上的端口,设置的时候,可以这样:

为什么按照上面的顺序操作?很多云服务器,都有默认的安全组或者防火墙配置,极有可能,默认情况下,除了 22 端口,其他都访问不了。所以,不要忙着取消 22 端口,而是先新增一个,测试一下联通性。不然,可能你退出了,就连不回来了。虽然,也不会有什么大的后果,但是会带来不少的麻烦。

优化SSH服务器端的性能

有一些常见的缺省设置,可能导致SSH服务的连接缓慢,简单调整参数,就可以使连接速度变快:

总结

感觉还有很多的细小的点没有总结全,不过这个帖子可以放着,慢慢总结吧。

发表评论

电子邮件地址不会被公开。 必填项已用*标注

This site uses Akismet to reduce spam. Learn how your comment data is processed.