2026年服务器默认密码依然是很多事故链条的第一环。新服务器开机找不到默认密码或者干脆没改就扔上生产环境这两件事几乎每天都在不同机房、不同云账号、不同办公区里重复上演。网上那些“各大厂商默认凭证大全”我劝你先别急着收藏。真正的问题不在于没有密码可查而在于这些资料大多过时、不可靠甚至本身就带着投毒和踩点的风险。与其去背一张靠不住的密码表不如把“默认凭证怎么获取、怎么登记、怎么替换、怎么长期防复发”这条链路打通。这篇内容主要写给三类人新接手服务器的小白、负责安全加固的工程师、做资产盘点和合规整改的运维同学。下面先从厂商出厂的密码策略变化开始说。1. 为什么“各大厂商默认密码大全”在2026年越来越不可靠早些年厂商为了避免用户配置门槛过高确实会在出厂固件里内置一套固定的管理员账号和弱口令设备拿到手直接用。那个年代的运维脑子里存着一张“密码表”就很管用。但现在再去翻这种表踩坑的概率远大于解决问题的概率。1.1 厂商默认口令的三阶段演进这些年默认口令的演变大概可以分三个阶段。第一阶段是通用固定口令时代。同一品牌、同一代际的设备所有出厂默认口令完全一样甚至不同型号之间也复用。好处是部署文档好写坏处是一旦泄漏整个互联网上同类设备都裸奔。第二阶段是批量生成口令时代。厂商开始意识到固定口令危险于是根据设备序列号、MAC地址、批次号等参数生成一组有规则可循的默认口令。这个阶段的口令已经不像从前那样全网通用但如果知道生成规则依然可以被预测。第三阶段是唯一随机口令与强制改密时代。这几年新出的服务器、网络设备、带外管理口很多不再有所谓“默认密码”了而是出厂时在机箱标签、密码封或初始化向导里下发一次性随机口令并强制你首次登录就修改。云服务器更是直接以密钥对代替密码登入把“默认凭证”这个概念整个去掉了。所以回到主题2026年再谈“最新各大厂商默认凭证大全”本身就是一件有点矛盾的事。厂商自己都在消灭默认凭证你还指望一张静态表格覆盖所有型号和版本这不现实。1.2 为什么照抄密码表容易出问题首先是时效性。一份简单的默认密码列表只对特定版本有效。固件一升级口令策略可能就改了。其次是版本和批次差异。同一个型号的产品不同批次可能采用不同的出厂口令策略。还有一种更坑的情况部分网上整理的“大全”会把管理员账号、密码、端口打包放一起看起来信息量大实际用得上的却没几条等到你急用时按这份列表去尝试极容易触发设备的登录失败锁定策略导致正规途径登录也被封禁。更值得警惕的是这类“密码大全”经常被人当成投毒载体。打包下载的文件里可能藏着木马页面访问也容易被收集设备指纹更不要提那些故意把弱口令字典伪装成“大全”来引流的行为。我实际排查过一起事件内网有人访问了一个所谓“默认密码在线查询站”后办公终端被下载了驱动级木马连杀毒软件都被静默关掉。所以现在我维护的任何服务器凡是需要参考默认凭证的一律只从厂商官方知识库拿绝不收藏来路不明的列表。真正有效的做法不是收藏一张全网通用的静态密码表而是把每一台设备的默认凭证纳入自己的台账形成一套“获取-登记-改密-复核”的动态管理机制。这也是我下面要展开的核心内容。2. 新服务器交付后默认凭证到底藏在哪里很多人拿到新服务器第一步是开机进系统到处找用户名和密码这是顺序反了。默认凭证的存放位置其实跟设备形态强相关先搞清楚你手里的是哪一类设备再去找凭证效率会高很多。2.1 物理服务器的带外管理口先看机箱标签和密码封物理服务器除了正常操作系统登录通常还有一块独立的带外管理芯片也就是常说的 BMC/IPMI。这块管理芯片有自己独立的IP、独立的账号体系用于远程开关机、看控制台、装系统。它对应的默认凭证一般不会放在操作系统里面而是印在服务器机箱外侧的标签上或者随机附带的一张“初始密码卡”上。有些厂商还要求在首次登录管理界面时强制修改初始密码修改后才允许进入系统模块。这些标签和卡片在验收拆箱时容易被忽略因为看起来像保修说明。我的建议是设备拆箱后先不要丢任何带条形码、二维码的卡片统一收集到一个信封里等完成首次登录、改密、备份配置之后再归档。如果你在机房看到一台新到的服务器标签上写着“Password: See Quick Start Card”那说明随机资料里一定有一张密码卡别把那个小纸板当废纸扔了。如果机箱上没有找到任何密码信息也不要直接去猜。多数品牌服务器BMC管理界面的出厂账号机制在官方文档库中输入序列号即可查询另外原厂售后支持也可以帮你拿到初始入口。带外管理的权限级别很高一定要保证它是从正常渠道拿到的。2.2 操作系统和虚拟化平台默认密码是“安装时你自己设的”操作系统层面其实没有所谓的“出厂默认密码”。Linux发行版装到一半会要求你设置root密码或者创建一个具备sudo权限的普通用户如果你在安装过程中跳过了这一步很多发行版会默认不允许root直接远程登录。Windows Server在安装过程中也必须设置本地Administrator密码不设置是过不去的。所以这是“安装时自己设定”的凭据完全不是默认密码。对于虚拟化平台来说比如服务器虚拟化、虚拟机管理平台首次部署时一般会在控制台界面初始化管理员账号和密码。也就是说系统层面的默认凭证完全应该记录在部署人员自己的文档里而不是指望从“默认密码大全”里找到答案。这里容易被忽略的是如果这台服务器是别人装好的交接时不给你部署记录那“初始安装密码”就会变成一个谁都不知道的谜。这种问题我给你放在后面第5节的复盘案例里讲。2.3 云服务器没有默认密码只有密钥对和控制台重置云服务器跟物理设备逻辑不一样。你在云控制台创建实例时要么选择SSH密钥对要么自己指定一个初始密码。如果你两种都没做基本上不可能用密码登入。而且大部分云平台不支持“查回初始密码”只支持“重置实例密码”重置之后旧密码立即失效。这其实是云厂商在刻意取消“默认密码”这个概念降低被撞库的风险。所以云服务器的“默认凭证”其实分为两块一是创建实例时设置的初始登录方式二是云账号本身的多因素认证和访问密钥。很多人在云上出问题不是实例密码弱而是云账号访问密钥泄漏。这个层面的“默认凭证管理”优先级比单台实例密码还要高。2.4 网络设备、安全设备、应用管理后台初始化向导会逼你改密交换、路由、防火墙、堡垒机、内网监控平台这类设备现在大多数在首次开机时就会进入初始化向导强制创建管理员和强密码。部分网络设备虽然保留了“恢复出厂设置”的机制但恢复后会进入初始化流程而不是回到一个固定默认密码可直接登录的状态。应用类服务更特殊。比如你自己搭了一套远程桌面中继服务、录播服务器推流平台、时间服务器管理系统等它的管理员初始密码通常是在安装脚本或配置文件中指定的或者安装完成后页面首次访问时自动跳转去设置。这种情况下配置时最常犯的错误是服务装完没改配置里的默认管理员口令就去对外开放。这个风险在真实生产环境中非常常见。为了便于记忆我常用下面这张表格来给新到手的资产归类设备类型凭证藏在哪首次登录常见要求最容易忽略的风险点物理服务器/BMC带外管理机箱标签、密码封、官方文档按SN查询强制首次登录改密拆箱时扔掉标签/密码卡操作系统/虚拟化平台安装过程中自行设定无固定默认密码缺少安装密码的交接记录云服务器密钥对/控制台重置无默认密码概念云账号访问密钥泄漏网络设备/安全设备初始化向导/随附卡片首次配置强制定跳过初始化直接放生产网数据库/中间件/应用后台安装配置文件中指定或安装向导生成建议启用MFA默认端口弱密码公网暴露3. 合规获取与登记与其背密码表不如建一张出厂凭证台账“默认凭证大全”如果用不好很容易变成一场事故发生的前奏。真正合规且高效的运维习惯是把每一台设备的默认凭证落到台账上进行生命周期管理。3.1 合规获取默认口令的四条正规渠道不要从二手博客、网盘资料包或各类“内部分享群”里下载默认密码列表。我实际工作中只建议走下面这些渠道产品随箱资料快速入门指南、密码信封、机箱贴纸、验收单。这是最权威的来源。厂商官网的知识库和文档中心输入设备型号或序列号通常能查到该型号出厂管理账号的初始化策略注意区分固件版本。原厂售后或工单支持尤其是企业级设备联系原厂技术支持时说明需求和设备SN他们可以给出标准答案。集成商移交资料从集成商手里接手的项目先要一份交付清单里面应包含设备台账、初始账号和密码、高层联系人信息。如果这四类渠道都拿不到默认凭证一般说明这台设备被重新刷过固件或者初始化过已经不是“出厂状态”此时老老实实走密码重置流程比反复尝试来得安全。反复尝试还容易触发设备锁定等到真想重置时反而要多等一段时间。3.2 台账字段默认凭证也要有“身份证”很多运维的资产台账只记录设备名称、IP、用途不记录默认凭证相关的元数据出了问题还是要到处打听。我给自己负责的资产建过一张默认凭证台账核心字段如下字段示例说明资产编号SRV-2026-001内部唯一编号与资产验收单保持一致设备名称/用途核心生产数据库一台设备可能跑多个服务在这里写最主要的厂商与型号某品牌服务器某型号型号决定初始化策略序列号SN-XXXX很多厂商按SN查默认口令序列号必须记出厂用户名admin / root / 物联标签等默认账号不写生产密码默认密码获取方式机箱标签/官方文档/售后保证合规溯源首次登录是否需要强制改密是/否影响上架前检查项当前生产密码存放位置密码管理器保险库不鼓励明文写在台账里最近一次改密时间2026-01-15用于后续轮换和审计责任人张三确保有人对这台设备负责这张表的目的不是把密码永远留在纸面上而是记录“这台机器的默认凭证是从哪来的、什么时候处理掉的、现在由谁负责”。密码本身放进密码管理器台账主要保留元数据和状态。3.3 用密码管理器接管默认凭证别让台账变泄密件默认凭证一旦被记录下来它本身就是敏感信息。如果再以Excel明文方式到处传那台账就变成了一张内网资产地图。我的习惯是台账可以给所有运维人员看但密码永远只在密码管理器里留。密码管理器选择什么品牌看团队习惯KeePass、Bitwarden、1Password都可以关键是必须启用主密码和二级认证并限制成员仅按需读取新改密前的初始密码。另外很多后台设备支持“一次性口令信封”功能即只有指定账号才能在首次开箱时通过后台获取初始密码其他人无法查看。碰到这种设备建议直接用系统提供的内部流程不要额外把密码导出到外部存储上。4. 拿到默认凭证后的五步加固法从登录开始就避免埋雷默认凭证不是用来长期保管的它的正确归宿是“用过就换”。下面这套步骤是我每次处理新服务器时都会走的不分厂商和类型都可以套用。4.1 登录前先做三项准备不要一拿到默认密码就直接登录生产环境。改密加固前先把快照和备份做好特别是在数据库和核心应用机器上确认服务器有可用的带外管理或者控制台访问通道防止修改SSH配置后把自己锁在系统外再找一个维护窗口尽量在业务低峰期操作避免登录行为触发监控告警。如果是物理服务器进入BMC管理界面后先把管理口IP、DNS、网关这些底层配置记录下来。改完操作系统密码后如果管理口网络配置出了问题还有机会回到带外控制台挽救。4.2 Linux服务器建立日常管理账户封掉root远程登录Linux下不建议长期用root密码远程登录。可以新建一个带sudo权限的日常用户确认这个用户可以正常登录后再禁用root的SSH远程登录。参考操作如下# 先以初始账号登录修改root密码 sudo passwd root # 创建日常管理用户并加入sudo组 sudo useradd -m -s /bin/bash ops-admin sudo passwd ops-admin sudo usermod -aG sudo ops-admin # 查看当前SSH配置里的root登录策略 grep ^PermitRootLogin /etc/ssh/sshd_config # 将PermitRootLogin改为no禁止root远程密码登录 sudo sed -i s/^#\?PermitRootLogin.*/PermitRootLogin no/ /etc/ssh/sshd_config # 测试SSH配置语法无误后重启sshd sudo sshd -t sudo systemctl restart sshd这里的关键点不是命令本身而是顺序一定先验证新用户能登录再重启sshd最后断开当前会话。如果直接在一台只有root远程登录的机器上禁用root而新用户还没有创建成功那这台机器就只能去机房或者带外控制台抢救了。有人会问既然都能sudo了为什么不直接禁用root因为root账户在系统维护模式、救援模式、定时任务里还是会有特殊用途直接禁用风险太高。更稳妥的做法是“保留账户禁止远程直登”日常操作都走sudo。4.3 Windows服务器新建管理账户重命名并收敛内置管理员Windows Server的默认本地管理员Administrator也是重点目标。直接删掉它可能影响后续故障恢复所以我更建议创建独立的管理员账户重命名内置Administrator验证新账户能登录后再考虑停用旧账户。# 创建新的本地管理员账户 $pw Read-Host -AsSecureString 请输入新管理员密码 New-LocalUser -Name srv-ops-01 -Password $pw Add-LocalGroupMember -Group Administrators -Member srv-ops-01 # 重命名内置Administrator Rename-LocalUser -Name Administrator -NewName old-admin-2026 # 确认新账户能登录系统后再禁用旧账户 Disable-LocalUser -Name old-admin-2026再配合Windows本地的安全策略把密码策略、账户锁定阈值、审核日志打开# 设置密码最长使用期为90天、锁定阈值为5次 net accounts /maxpwage:90 net accounts /lockoutthreshold:5 # 开启安全日志记录并把日志上限提到200MB wevtutil set-log Security /enabled:true /retention:true /maxsize:204800如果是云上的Windows实例改完本地管理员后还要检查云平台的安全组规则限制远程桌面端口的来源IP不要对全网开放默认远程端口。这是默认凭证之外最容易被人盯上的点。4.4 数据库和管理设备的默认账号处理数据库的默认账号往往权限极高。MySQL的root默认在本地是没问题的但前提是只监听本机、不允许匿名用户并设置强密码。类似这样ALTER USER rootlocalhost IDENTIFIED WITH caching_sha2_password BY 在这里替换成强密码; DELETE FROM mysql.user WHERE User; FLUSH PRIVILEGES;不要把远程开发账号直接建在root上应该创建最小权限的独立账号只开放业务需要的库和表。Redis这类服务如果不需要外部访问建议把bind绑定地址改为127.0.0.1并开启访问密码避免默认无口令暴露。网络设备、防火墙管理页面的处理逻辑也是一样的改掉管理页面的默认端口或访问路径限制管理来源网段开启登录失败锁定。对于堡垒机、远程桌面中继、时间服务器管理后台这类自建应用默认账号不要直接使用安装脚本里如果带了初始密码务必在初始化时替换。不少应用第一次访问页面时会给一个临时口令很多人在测试环境跑通后忘了改等上了生产才发现后台还是用临时口令撑着这就是隐患。4.5 改密后的验证和回退改完密码不是结束是新的开始。我的固定动作是保留一个已登录的会话不要立刻退出新开一个窗口用新密码登录确认能进系统、权限正常、业务服务在跑再关闭旧会话。如果遇上数据库主从集群还要验证主从同步状态是否正常有些高权限账户变更会影响复制链路。一旦发现新密码登录后业务异常先不要慌回退到上一个可用状态。物理机器可以通过带外管理界面进入救援模式或单用户模式云服务器可以通过控制台重置密码或挂载救援系统处理。这就是为什么前面强调登录前先做快照因为在紧急回退时快照是最保险的后悔药。5. 复盘我处理过的三次默认凭证“翻车”理论讲完了说说实际踩过的坑。这三件事都跟默认凭证有关给了我很深的印象。5.1 新机房设备全部使用出厂密码差点被自动扫描打穿有一次接手一个新建机房项目几十台服务器加网络设备同时上架。项目方为了赶进度把设备默认口令原封不动地保留着打算先通业务再抽空补安全。结果机器刚接上管理网就有运维兄弟发现带外管理口一直在报登录失败登录日志里能看到来自不同IP的自动扫描尝试。排查下来问题出在带外管理口直接接到了业务网段而设备出厂账号和初始口令又没有改等于把钥匙挂在门口。好在发现得早没有造成实质影响。处理方式是先把管理网段做ACL隔离只允许运维跳板机的IP访问然后分批登录每一台设备把默认凭证全部改掉并开启登录失败锁定策略最后把整个机房的设备指纹和账号状态重新盘点了一遍。这次之后我形成了一个习惯新设备上线前必须做一次“默认口令清零”没有清零的设备不允许接入生产网络。哪怕只晚一天上架也比出事之后再停机整改强。5.2 交接时没有记录初始密码服务器被锁在门外另一件事是有人重新部署一台Linux服务器时装完系统顺手设了一个密码也没写进交接文档。过了两个月负责部署的人休假了另一位运维要登录上去处理业务结果试遍所有已知密码都进不去。当时第一反应是恢复密码但机器不在本地机房只能通过远程管理口操作。好在带外管理控制台还能进于是走了一遍Linux救援模式流程通过带外控制台挂载系统安装介质进入rescue环境后切换root目录、修改密码文件把登录密码重置成一个新值再把业务服务重新拉起。整件事不难但耗时将近两个小时还申请了一个变更窗口。如果当初部署完成时顺手把密码记录进密码管理器并把资产台账更新好完全不用折腾这么长时间。很多默认凭证问题本质上不是技术问题而是记录和交接的问题。5.3 内网Web系统默认管理员账号跳过了“强密码策略”还有一个案例某个内网业务系统在安装时保留了默认的管理员账号管理员路由也还是默认路径。安全扫描时发现该系统正在被尝试登录虽然触发了登录失败锁定但从日志来看攻击者是先猜到了管理后台的入口再试图爆破默认账号。原因是系统的“强制强密码策略”只对新设置的密码生效默认管理员账号的密码策略被排除在外所以即使全站都要求强密码默认账号依然是弱口令状态。最后处理时做了三件事把默认的管理员账号重命名并设置独立强密码修改管理后台的访问路径开启双重认证和登录验证码。同时在基线检查里新增了一条规则专门检查是否存在未改密的默认管理员账号。6. 后续怎么防止默认凭证“卷土重来”一次改密解决不了长期问题。只要新设备一直在采购、人员一直在变动默认凭证的风险就会不断重新出现。6.1 三个必须检查的时间点到货、上架、人员变动到货验收时必须收集密码封和机箱标签信息登记进台账。设备上架时执行改密、加固、备份配置三步曲确认完成才允许接入生产网。人员变动时要判断这个人是否接触过默认凭证台账如果接触过相关设备的密码和管理员账号应安排一次轮换。最容易被忽略的是人员离职后的权限回收。很多人以为删掉云账号就可以了但设备本身的本地管理员密码如果还保留着旧密码离职员工依然可以通过本地账号进入设备。除非这台设备上所有本地管理员密码都已经轮换否则风险一直在。6.2 把默认口令检查放进自动化基线巡检人工检查总有遗漏建议把默认凭证检查做成自动化。现在不少配置管理工具和主机安全产品都支持自定义基线规则可以设计成新加入的资产如果在48小时内没有完成密码修改记录自动在运维群里推送告警管理口如果对非运维来源IP放开自动触发工单。另外登录日志和操作审计要长期保留。默认凭证这件事很难靠一次扫描彻底清零但通过日志和审计可以发现异常登录行为比如一个账号在凌晨三点从陌生IP登录管理口那多半是有问题了。6.3 资产下线时也要清理默认凭证设备淘汰和下架时很多人只关心业务迁移忘记清掉设备上的账号配置。设备如果进入二手市场或者统一回收里面的默认凭证、重置机制、管理账户信息都应该彻底清除。二手服务器如果带有原单位的带外管理账号和密码一旦被人拿到并开机就能直接进入管理界面。无论从安全角度还是从数据合规角度都应该在设备退网前做一次恢复出厂和介质擦除。最后说一个我自己的习惯任何一台设备经过我手上第一次登录成功后第一件事不是去看业务而是先在密码管理器里建一条资产记录再把默认密码改掉。虽然只多花几分钟后面省下的找密码时间、被锁在门外的尴尬和半夜被叫起来处理告警的次数远超我投入的这点成本。默认凭证这件事从来不是“收藏密码越多越专业”而是“知道自己的机器上都有哪些原始入口并且确保它们全部处于可控状态”。
2026年服务器默认密码依然是很多事故链条的第一环。新服务器开机找不到默认密码或者干脆没改就扔上生产环境这两件事几乎每天都在不同机房、不同云账号、不同办公区里重复上演。网上那些“各大厂商默认凭证大全”我劝你先别急着收藏。真正的问题不在于没有密码可查而在于这些资料大多过时、不可靠甚至本身就带着投毒和踩点的风险。与其去背一张靠不住的密码表不如把“默认凭证怎么获取、怎么登记、怎么替换、怎么长期防复发”这条链路打通。这篇内容主要写给三类人新接手服务器的小白、负责安全加固的工程师、做资产盘点和合规整改的运维同学。下面先从厂商出厂的密码策略变化开始说。1. 为什么“各大厂商默认密码大全”在2026年越来越不可靠早些年厂商为了避免用户配置门槛过高确实会在出厂固件里内置一套固定的管理员账号和弱口令设备拿到手直接用。那个年代的运维脑子里存着一张“密码表”就很管用。但现在再去翻这种表踩坑的概率远大于解决问题的概率。1.1 厂商默认口令的三阶段演进这些年默认口令的演变大概可以分三个阶段。第一阶段是通用固定口令时代。同一品牌、同一代际的设备所有出厂默认口令完全一样甚至不同型号之间也复用。好处是部署文档好写坏处是一旦泄漏整个互联网上同类设备都裸奔。第二阶段是批量生成口令时代。厂商开始意识到固定口令危险于是根据设备序列号、MAC地址、批次号等参数生成一组有规则可循的默认口令。这个阶段的口令已经不像从前那样全网通用但如果知道生成规则依然可以被预测。第三阶段是唯一随机口令与强制改密时代。这几年新出的服务器、网络设备、带外管理口很多不再有所谓“默认密码”了而是出厂时在机箱标签、密码封或初始化向导里下发一次性随机口令并强制你首次登录就修改。云服务器更是直接以密钥对代替密码登入把“默认凭证”这个概念整个去掉了。所以回到主题2026年再谈“最新各大厂商默认凭证大全”本身就是一件有点矛盾的事。厂商自己都在消灭默认凭证你还指望一张静态表格覆盖所有型号和版本这不现实。1.2 为什么照抄密码表容易出问题首先是时效性。一份简单的默认密码列表只对特定版本有效。固件一升级口令策略可能就改了。其次是版本和批次差异。同一个型号的产品不同批次可能采用不同的出厂口令策略。还有一种更坑的情况部分网上整理的“大全”会把管理员账号、密码、端口打包放一起看起来信息量大实际用得上的却没几条等到你急用时按这份列表去尝试极容易触发设备的登录失败锁定策略导致正规途径登录也被封禁。更值得警惕的是这类“密码大全”经常被人当成投毒载体。打包下载的文件里可能藏着木马页面访问也容易被收集设备指纹更不要提那些故意把弱口令字典伪装成“大全”来引流的行为。我实际排查过一起事件内网有人访问了一个所谓“默认密码在线查询站”后办公终端被下载了驱动级木马连杀毒软件都被静默关掉。所以现在我维护的任何服务器凡是需要参考默认凭证的一律只从厂商官方知识库拿绝不收藏来路不明的列表。真正有效的做法不是收藏一张全网通用的静态密码表而是把每一台设备的默认凭证纳入自己的台账形成一套“获取-登记-改密-复核”的动态管理机制。这也是我下面要展开的核心内容。2. 新服务器交付后默认凭证到底藏在哪里很多人拿到新服务器第一步是开机进系统到处找用户名和密码这是顺序反了。默认凭证的存放位置其实跟设备形态强相关先搞清楚你手里的是哪一类设备再去找凭证效率会高很多。2.1 物理服务器的带外管理口先看机箱标签和密码封物理服务器除了正常操作系统登录通常还有一块独立的带外管理芯片也就是常说的 BMC/IPMI。这块管理芯片有自己独立的IP、独立的账号体系用于远程开关机、看控制台、装系统。它对应的默认凭证一般不会放在操作系统里面而是印在服务器机箱外侧的标签上或者随机附带的一张“初始密码卡”上。有些厂商还要求在首次登录管理界面时强制修改初始密码修改后才允许进入系统模块。这些标签和卡片在验收拆箱时容易被忽略因为看起来像保修说明。我的建议是设备拆箱后先不要丢任何带条形码、二维码的卡片统一收集到一个信封里等完成首次登录、改密、备份配置之后再归档。如果你在机房看到一台新到的服务器标签上写着“Password: See Quick Start Card”那说明随机资料里一定有一张密码卡别把那个小纸板当废纸扔了。如果机箱上没有找到任何密码信息也不要直接去猜。多数品牌服务器BMC管理界面的出厂账号机制在官方文档库中输入序列号即可查询另外原厂售后支持也可以帮你拿到初始入口。带外管理的权限级别很高一定要保证它是从正常渠道拿到的。2.2 操作系统和虚拟化平台默认密码是“安装时你自己设的”操作系统层面其实没有所谓的“出厂默认密码”。Linux发行版装到一半会要求你设置root密码或者创建一个具备sudo权限的普通用户如果你在安装过程中跳过了这一步很多发行版会默认不允许root直接远程登录。Windows Server在安装过程中也必须设置本地Administrator密码不设置是过不去的。所以这是“安装时自己设定”的凭据完全不是默认密码。对于虚拟化平台来说比如服务器虚拟化、虚拟机管理平台首次部署时一般会在控制台界面初始化管理员账号和密码。也就是说系统层面的默认凭证完全应该记录在部署人员自己的文档里而不是指望从“默认密码大全”里找到答案。这里容易被忽略的是如果这台服务器是别人装好的交接时不给你部署记录那“初始安装密码”就会变成一个谁都不知道的谜。这种问题我给你放在后面第5节的复盘案例里讲。2.3 云服务器没有默认密码只有密钥对和控制台重置云服务器跟物理设备逻辑不一样。你在云控制台创建实例时要么选择SSH密钥对要么自己指定一个初始密码。如果你两种都没做基本上不可能用密码登入。而且大部分云平台不支持“查回初始密码”只支持“重置实例密码”重置之后旧密码立即失效。这其实是云厂商在刻意取消“默认密码”这个概念降低被撞库的风险。所以云服务器的“默认凭证”其实分为两块一是创建实例时设置的初始登录方式二是云账号本身的多因素认证和访问密钥。很多人在云上出问题不是实例密码弱而是云账号访问密钥泄漏。这个层面的“默认凭证管理”优先级比单台实例密码还要高。2.4 网络设备、安全设备、应用管理后台初始化向导会逼你改密交换、路由、防火墙、堡垒机、内网监控平台这类设备现在大多数在首次开机时就会进入初始化向导强制创建管理员和强密码。部分网络设备虽然保留了“恢复出厂设置”的机制但恢复后会进入初始化流程而不是回到一个固定默认密码可直接登录的状态。应用类服务更特殊。比如你自己搭了一套远程桌面中继服务、录播服务器推流平台、时间服务器管理系统等它的管理员初始密码通常是在安装脚本或配置文件中指定的或者安装完成后页面首次访问时自动跳转去设置。这种情况下配置时最常犯的错误是服务装完没改配置里的默认管理员口令就去对外开放。这个风险在真实生产环境中非常常见。为了便于记忆我常用下面这张表格来给新到手的资产归类设备类型凭证藏在哪首次登录常见要求最容易忽略的风险点物理服务器/BMC带外管理机箱标签、密码封、官方文档按SN查询强制首次登录改密拆箱时扔掉标签/密码卡操作系统/虚拟化平台安装过程中自行设定无固定默认密码缺少安装密码的交接记录云服务器密钥对/控制台重置无默认密码概念云账号访问密钥泄漏网络设备/安全设备初始化向导/随附卡片首次配置强制定跳过初始化直接放生产网数据库/中间件/应用后台安装配置文件中指定或安装向导生成建议启用MFA默认端口弱密码公网暴露3. 合规获取与登记与其背密码表不如建一张出厂凭证台账“默认凭证大全”如果用不好很容易变成一场事故发生的前奏。真正合规且高效的运维习惯是把每一台设备的默认凭证落到台账上进行生命周期管理。3.1 合规获取默认口令的四条正规渠道不要从二手博客、网盘资料包或各类“内部分享群”里下载默认密码列表。我实际工作中只建议走下面这些渠道产品随箱资料快速入门指南、密码信封、机箱贴纸、验收单。这是最权威的来源。厂商官网的知识库和文档中心输入设备型号或序列号通常能查到该型号出厂管理账号的初始化策略注意区分固件版本。原厂售后或工单支持尤其是企业级设备联系原厂技术支持时说明需求和设备SN他们可以给出标准答案。集成商移交资料从集成商手里接手的项目先要一份交付清单里面应包含设备台账、初始账号和密码、高层联系人信息。如果这四类渠道都拿不到默认凭证一般说明这台设备被重新刷过固件或者初始化过已经不是“出厂状态”此时老老实实走密码重置流程比反复尝试来得安全。反复尝试还容易触发设备锁定等到真想重置时反而要多等一段时间。3.2 台账字段默认凭证也要有“身份证”很多运维的资产台账只记录设备名称、IP、用途不记录默认凭证相关的元数据出了问题还是要到处打听。我给自己负责的资产建过一张默认凭证台账核心字段如下字段示例说明资产编号SRV-2026-001内部唯一编号与资产验收单保持一致设备名称/用途核心生产数据库一台设备可能跑多个服务在这里写最主要的厂商与型号某品牌服务器某型号型号决定初始化策略序列号SN-XXXX很多厂商按SN查默认口令序列号必须记出厂用户名admin / root / 物联标签等默认账号不写生产密码默认密码获取方式机箱标签/官方文档/售后保证合规溯源首次登录是否需要强制改密是/否影响上架前检查项当前生产密码存放位置密码管理器保险库不鼓励明文写在台账里最近一次改密时间2026-01-15用于后续轮换和审计责任人张三确保有人对这台设备负责这张表的目的不是把密码永远留在纸面上而是记录“这台机器的默认凭证是从哪来的、什么时候处理掉的、现在由谁负责”。密码本身放进密码管理器台账主要保留元数据和状态。3.3 用密码管理器接管默认凭证别让台账变泄密件默认凭证一旦被记录下来它本身就是敏感信息。如果再以Excel明文方式到处传那台账就变成了一张内网资产地图。我的习惯是台账可以给所有运维人员看但密码永远只在密码管理器里留。密码管理器选择什么品牌看团队习惯KeePass、Bitwarden、1Password都可以关键是必须启用主密码和二级认证并限制成员仅按需读取新改密前的初始密码。另外很多后台设备支持“一次性口令信封”功能即只有指定账号才能在首次开箱时通过后台获取初始密码其他人无法查看。碰到这种设备建议直接用系统提供的内部流程不要额外把密码导出到外部存储上。4. 拿到默认凭证后的五步加固法从登录开始就避免埋雷默认凭证不是用来长期保管的它的正确归宿是“用过就换”。下面这套步骤是我每次处理新服务器时都会走的不分厂商和类型都可以套用。4.1 登录前先做三项准备不要一拿到默认密码就直接登录生产环境。改密加固前先把快照和备份做好特别是在数据库和核心应用机器上确认服务器有可用的带外管理或者控制台访问通道防止修改SSH配置后把自己锁在系统外再找一个维护窗口尽量在业务低峰期操作避免登录行为触发监控告警。如果是物理服务器进入BMC管理界面后先把管理口IP、DNS、网关这些底层配置记录下来。改完操作系统密码后如果管理口网络配置出了问题还有机会回到带外控制台挽救。4.2 Linux服务器建立日常管理账户封掉root远程登录Linux下不建议长期用root密码远程登录。可以新建一个带sudo权限的日常用户确认这个用户可以正常登录后再禁用root的SSH远程登录。参考操作如下# 先以初始账号登录修改root密码 sudo passwd root # 创建日常管理用户并加入sudo组 sudo useradd -m -s /bin/bash ops-admin sudo passwd ops-admin sudo usermod -aG sudo ops-admin # 查看当前SSH配置里的root登录策略 grep ^PermitRootLogin /etc/ssh/sshd_config # 将PermitRootLogin改为no禁止root远程密码登录 sudo sed -i s/^#\?PermitRootLogin.*/PermitRootLogin no/ /etc/ssh/sshd_config # 测试SSH配置语法无误后重启sshd sudo sshd -t sudo systemctl restart sshd这里的关键点不是命令本身而是顺序一定先验证新用户能登录再重启sshd最后断开当前会话。如果直接在一台只有root远程登录的机器上禁用root而新用户还没有创建成功那这台机器就只能去机房或者带外控制台抢救了。有人会问既然都能sudo了为什么不直接禁用root因为root账户在系统维护模式、救援模式、定时任务里还是会有特殊用途直接禁用风险太高。更稳妥的做法是“保留账户禁止远程直登”日常操作都走sudo。4.3 Windows服务器新建管理账户重命名并收敛内置管理员Windows Server的默认本地管理员Administrator也是重点目标。直接删掉它可能影响后续故障恢复所以我更建议创建独立的管理员账户重命名内置Administrator验证新账户能登录后再考虑停用旧账户。# 创建新的本地管理员账户 $pw Read-Host -AsSecureString 请输入新管理员密码 New-LocalUser -Name srv-ops-01 -Password $pw Add-LocalGroupMember -Group Administrators -Member srv-ops-01 # 重命名内置Administrator Rename-LocalUser -Name Administrator -NewName old-admin-2026 # 确认新账户能登录系统后再禁用旧账户 Disable-LocalUser -Name old-admin-2026再配合Windows本地的安全策略把密码策略、账户锁定阈值、审核日志打开# 设置密码最长使用期为90天、锁定阈值为5次 net accounts /maxpwage:90 net accounts /lockoutthreshold:5 # 开启安全日志记录并把日志上限提到200MB wevtutil set-log Security /enabled:true /retention:true /maxsize:204800如果是云上的Windows实例改完本地管理员后还要检查云平台的安全组规则限制远程桌面端口的来源IP不要对全网开放默认远程端口。这是默认凭证之外最容易被人盯上的点。4.4 数据库和管理设备的默认账号处理数据库的默认账号往往权限极高。MySQL的root默认在本地是没问题的但前提是只监听本机、不允许匿名用户并设置强密码。类似这样ALTER USER rootlocalhost IDENTIFIED WITH caching_sha2_password BY 在这里替换成强密码; DELETE FROM mysql.user WHERE User; FLUSH PRIVILEGES;不要把远程开发账号直接建在root上应该创建最小权限的独立账号只开放业务需要的库和表。Redis这类服务如果不需要外部访问建议把bind绑定地址改为127.0.0.1并开启访问密码避免默认无口令暴露。网络设备、防火墙管理页面的处理逻辑也是一样的改掉管理页面的默认端口或访问路径限制管理来源网段开启登录失败锁定。对于堡垒机、远程桌面中继、时间服务器管理后台这类自建应用默认账号不要直接使用安装脚本里如果带了初始密码务必在初始化时替换。不少应用第一次访问页面时会给一个临时口令很多人在测试环境跑通后忘了改等上了生产才发现后台还是用临时口令撑着这就是隐患。4.5 改密后的验证和回退改完密码不是结束是新的开始。我的固定动作是保留一个已登录的会话不要立刻退出新开一个窗口用新密码登录确认能进系统、权限正常、业务服务在跑再关闭旧会话。如果遇上数据库主从集群还要验证主从同步状态是否正常有些高权限账户变更会影响复制链路。一旦发现新密码登录后业务异常先不要慌回退到上一个可用状态。物理机器可以通过带外管理界面进入救援模式或单用户模式云服务器可以通过控制台重置密码或挂载救援系统处理。这就是为什么前面强调登录前先做快照因为在紧急回退时快照是最保险的后悔药。5. 复盘我处理过的三次默认凭证“翻车”理论讲完了说说实际踩过的坑。这三件事都跟默认凭证有关给了我很深的印象。5.1 新机房设备全部使用出厂密码差点被自动扫描打穿有一次接手一个新建机房项目几十台服务器加网络设备同时上架。项目方为了赶进度把设备默认口令原封不动地保留着打算先通业务再抽空补安全。结果机器刚接上管理网就有运维兄弟发现带外管理口一直在报登录失败登录日志里能看到来自不同IP的自动扫描尝试。排查下来问题出在带外管理口直接接到了业务网段而设备出厂账号和初始口令又没有改等于把钥匙挂在门口。好在发现得早没有造成实质影响。处理方式是先把管理网段做ACL隔离只允许运维跳板机的IP访问然后分批登录每一台设备把默认凭证全部改掉并开启登录失败锁定策略最后把整个机房的设备指纹和账号状态重新盘点了一遍。这次之后我形成了一个习惯新设备上线前必须做一次“默认口令清零”没有清零的设备不允许接入生产网络。哪怕只晚一天上架也比出事之后再停机整改强。5.2 交接时没有记录初始密码服务器被锁在门外另一件事是有人重新部署一台Linux服务器时装完系统顺手设了一个密码也没写进交接文档。过了两个月负责部署的人休假了另一位运维要登录上去处理业务结果试遍所有已知密码都进不去。当时第一反应是恢复密码但机器不在本地机房只能通过远程管理口操作。好在带外管理控制台还能进于是走了一遍Linux救援模式流程通过带外控制台挂载系统安装介质进入rescue环境后切换root目录、修改密码文件把登录密码重置成一个新值再把业务服务重新拉起。整件事不难但耗时将近两个小时还申请了一个变更窗口。如果当初部署完成时顺手把密码记录进密码管理器并把资产台账更新好完全不用折腾这么长时间。很多默认凭证问题本质上不是技术问题而是记录和交接的问题。5.3 内网Web系统默认管理员账号跳过了“强密码策略”还有一个案例某个内网业务系统在安装时保留了默认的管理员账号管理员路由也还是默认路径。安全扫描时发现该系统正在被尝试登录虽然触发了登录失败锁定但从日志来看攻击者是先猜到了管理后台的入口再试图爆破默认账号。原因是系统的“强制强密码策略”只对新设置的密码生效默认管理员账号的密码策略被排除在外所以即使全站都要求强密码默认账号依然是弱口令状态。最后处理时做了三件事把默认的管理员账号重命名并设置独立强密码修改管理后台的访问路径开启双重认证和登录验证码。同时在基线检查里新增了一条规则专门检查是否存在未改密的默认管理员账号。6. 后续怎么防止默认凭证“卷土重来”一次改密解决不了长期问题。只要新设备一直在采购、人员一直在变动默认凭证的风险就会不断重新出现。6.1 三个必须检查的时间点到货、上架、人员变动到货验收时必须收集密码封和机箱标签信息登记进台账。设备上架时执行改密、加固、备份配置三步曲确认完成才允许接入生产网。人员变动时要判断这个人是否接触过默认凭证台账如果接触过相关设备的密码和管理员账号应安排一次轮换。最容易被忽略的是人员离职后的权限回收。很多人以为删掉云账号就可以了但设备本身的本地管理员密码如果还保留着旧密码离职员工依然可以通过本地账号进入设备。除非这台设备上所有本地管理员密码都已经轮换否则风险一直在。6.2 把默认口令检查放进自动化基线巡检人工检查总有遗漏建议把默认凭证检查做成自动化。现在不少配置管理工具和主机安全产品都支持自定义基线规则可以设计成新加入的资产如果在48小时内没有完成密码修改记录自动在运维群里推送告警管理口如果对非运维来源IP放开自动触发工单。另外登录日志和操作审计要长期保留。默认凭证这件事很难靠一次扫描彻底清零但通过日志和审计可以发现异常登录行为比如一个账号在凌晨三点从陌生IP登录管理口那多半是有问题了。6.3 资产下线时也要清理默认凭证设备淘汰和下架时很多人只关心业务迁移忘记清掉设备上的账号配置。设备如果进入二手市场或者统一回收里面的默认凭证、重置机制、管理账户信息都应该彻底清除。二手服务器如果带有原单位的带外管理账号和密码一旦被人拿到并开机就能直接进入管理界面。无论从安全角度还是从数据合规角度都应该在设备退网前做一次恢复出厂和介质擦除。最后说一个我自己的习惯任何一台设备经过我手上第一次登录成功后第一件事不是去看业务而是先在密码管理器里建一条资产记录再把默认密码改掉。虽然只多花几分钟后面省下的找密码时间、被锁在门外的尴尬和半夜被叫起来处理告警的次数远超我投入的这点成本。默认凭证这件事从来不是“收藏密码越多越专业”而是“知道自己的机器上都有哪些原始入口并且确保它们全部处于可控状态”。
