加固之前先做一次摸底，看看服务器正在被怎么对待。登录日志里通常记录着每次尝试的来源、账号和时间，翻一翻就能发现规律：被尝试最多的账号名是什么，尝试集中在哪个时段，是不是来自固定的几段地址。这些信息决定了加固的重点，如果被尝试的都是默认账号，说明扫描器还没摸清你的实际情况；如果已经出现了真实存在的用户名，那说明有人做过调查。
第一件事是把入口从默认位置挪开。管理端口换成一个不常用的高位端口，能过滤掉绝大多数自动化扫描，因为它们只按默认值去找。改端口这件事的收益常常被低估：它不是安全上的根本手段，但能以极低的成本把噪音降下来，让日志里剩下的记录更容易分辨。
端口调整之后要确认防火墙和安全组同步放行，并且保留一个备用通道，避免改错了连不上。
这是整个加固里最关键的一步。生成一对密钥，把公钥放到服务器上，关闭密码认证。这样即便对方知道用户名，也没有可以猜的东西。私钥自己保管，加一个保护口令，不要放在跳板机的公共目录里；换机器时记得把旧的公钥从服务器上删掉。
同时要禁止最高权限账号直接登录，日常操作走普通账号，需要提权时再走提权命令，并且把提权操作记入日志。这样做的另一个好处是能分清每个人的操作，而不是所有人都用同一个身份。
在安全组里把管理端口的来源收窄到公司出口或者跳板机，是从源头上减少尝试的办法。再配上失败次数限制，同一个来源连续失败若干次之后就暂时拒绝，可以进一步降低被猜中的概率。有些环境还会在提权时要求第二重验证，把门槛再抬高一截。
验证方法很直接：用密码尝试登录，看是否被拒绝；用普通账号试一下不能执行的操作，看是否被拦下；从非白名单地址连管理端口，看是否连不上。改完之后把改动内容记录下来，包括端口、认证方式、白名单范围，否则下次交接或者重装系统时，很可能又被改回默认状态。
加固不是一次性的动作。新增运维人员、更换跳板机、调整出口地址，都会影响这套配置，每次变更之后回头确认一遍，比事后补救省事得多。
加固做完之后，平时的动作比一次性的配置更重要。新增运维人员时，账号单独建、密钥单独生成，不要多人共用一套；有人离职或者岗位调整，第一时间收回。共用账号最大的问题是出了事查不到人，日志里看到的永远是同一个名字。
客户端保存的配置也要跟着更新。改过端口、换过密钥之后，本地的配置文件和脚本里的旧信息如果没同步，下次自动任务就会失败，而失败往往要到半夜才被发现。改完一遍之后，把所有引用到这些信息的地方都过一遍。
另外，密钥文件不要随手放在共享目录或者代码仓库里。加一层口令保护，再多记一句说明它用在哪里，交接时能省掉很多解释。
密钥换了之后，备份任务、监控采集、部署脚本里可能还在用旧的。这些位置平时不声不响，出问题时又不在主流程上，排查起来最费时间，改完一定要逐项确认。
重要操作记得在多人可见的地方留一句说明。一个人半夜改完配置，第二天别人看不懂状态，很容易重复劳动或者改错方向。
日志级别也别一直开着最详细的那种。信息太多反而看不到重点，还会把磁盘占满，出事时最需要的那段历史反倒被滚掉了。
关机重启、凭据轮换这类动作写成固定流程，谁来执行都是同一套步骤，出错的机会就小很多。这些细节单看都不大，却决定了日常运维是否省心。
把这几件事排进例行轨道，比依赖某个人的习惯可靠得多。工具能提醒的部分尽量交给工具，人只处理例外情况，效率和安全都不容易打折。
售后客服
企业微信
