很多第一次部署ClickHouse的朋友估计都遇到过这样一个让我印象深刻的瞬间装好服务敲下clickhouse-client连密码都不用输直接回车就进了SQL命令行。我第一次帮同事排查ClickHouse集群时就被这个默认行为惊到了——在默认配置下default用户是没有密码的这在任何暴露的网络环境里都等于把数据库大门敞开着。今天这篇文章就围绕“给ClickHouse默认用户default设置密码”这件事把我实际用过的几种方式、在线修改与配置文件修改之间的取舍、以及生产环境里踩过的坑完整梳理一遍。刚入门的运维新人也好接手了历史遗留旧集群的老手也好这篇内容都可以直接参考照着操作。1. 为什么ClickHouse的default用户一开始是“裸奔”的1.1 默认配置下的default用户到底是什么样ClickHouse安装完成之后默认会生成一个叫default的用户这个用户从设计之初就为了“开箱即用”做了很多妥协。最典型的一点就是在/etc/clickhouse-server/users.xml这个文件里default用户段落通常只有几个关键配置项比如networks、profile、quota唯独没有密码相关的字段。我直接说结论没有密码字段就等同于空密码。也就是说在默认情况下任何能通过网络访问到ClickHouse端口的人都可以用default用户名直接登录不需要任何凭证。配合ClickHouse默认的9000端口TCP原生协议和8123端口HTTP接口只要服务器IP暴露在公网或办公网内数据被扫描和拖走只是时间问题。很多刚接触ClickHouse的人会把精力花在配置表结构、调优参数上忽略了用户认证这一层。但我的经验是用户认证和网络访问控制才是ClickHouse部署之后第一个要处理的事情。原因很简单功能再强大数据安全兜不住底后面全是麻烦。网上也时不时能看到某团队因为ClickHouse没设密码、端口暴露在公网导致数据库被恶意清空甚至被勒索的案例这类事一旦发生几乎没有后悔药。1.2 ClickHouse的认证方式有哪些怎么选ClickHouse的用户认证方式并不只有密码这一种但真正在日常运维里用得最多的基本就是以下几类password明文密码直接写在配置里简单但不安全。password_sha256_hex存储密码的SHA256哈希值配置里看不到明文推荐使用。password_double_sha256_hex存储两次SHA256后的哈希值主要用于兼容早期MySQL客户端协议场景。LDAP认证、SSL证书认证等适合企业级统一认证体系但配置复杂度高一般团队用不上。从运维角度来说我建议优先使用password_sha256_hex。原因很简单配置文件的权限管控通常没有想象中那么严格如果密码以明文形式存在users.xml里任何一个能读到服务器文件的账号都能拿到数据库密码等于设了和没设一样。而SHA256哈希即使被看到也不能直接反推出原始密码安全性高一个档次。这里还要补充一个容易被忽略的细节ClickHouse的密码哈希不是对文件或者用户名做哈希而是对“密码本身”做SHA256。所以同一个密码在任何机器上生成的哈希都是一样的这也意味着哈希一旦泄露仍然存在被暴力破解或撞库的风险因此密码本身的强度依然很重要。2. 设置default密码的三种主流方式2.1 最直观的方式在users.xml里直接写明文密码很多教程第一步就会带你打开/etc/clickhouse-server/users.xml然后在default节点下加一行default passwordMyStrongPassw0rd!/password networks ip::/0/ip /networks profiledefault/profile quotadefault/quota /default这种方式改起来最快重启ClickHouse服务后密码立刻生效。我用“最直观”来形容它是因为它的逻辑一眼就能看懂不需要生成任何哈希也不涉及额外的命令。但它的缺点同样明显。第一密码明文出现在配置文件里服务器上其他账号只要能读这个文件就能拿到密码第二很多团队会把配置文件提交到Git仓库或者内部文档系统里明文密码很容易在不知不觉中泄露出去第三一旦有人截图或者复制了配置文件的内容发到聊天工具里密码就成了“公开的秘密”。所以我个人很少在生产环境用明文方式最多就是在本地临时测试环境图省事用一下。2.2 我推荐的方式在users.xml里写入SHA256哈希既然不推荐明文那生产环境怎么搞我的习惯是先把密码用SHA256算法做一次哈希再把哈希值写进users.xml。具体生成命令很简单echo -n MyStrongPassw0rd! | sha256sum这里必须强调一下echo -n的-n参数不能丢。如果漏了-n字符串后面会带一个换行符算出来的哈希跟不带换行符的哈希完全是两个值而且这种错误肉眼几乎看不出来。我之前就见过同事配置完之后怎么都登录不上折腾了半天才发现是echo命令漏了-n。拿到哈希之后把它填到users.xml里default password_sha256_hex5e884898da28047151d0e56f8dc6292773603d0d6aabbdd62a11ef721d1542d8/password_sha256_hex networks ip::/0/ip /networks profiledefault/profile quotadefault/quota /default修改完保存然后重启ClickHouse服务密码就会按SHA256方式校验。我个人在实际生产环境里基本都是用这种方式因为它既不牺牲安全性也不需要额外维护一套用户管理组件对单机或小规模集群来说性价比最高。2.3 更灵活的方式用SQL用户管理在线修改如果你的ClickHouse版本在21.x以上还有一种更省事的方式直接用SQL语句在线修改用户密码不需要重启服务。ClickHouse从较新版本开始支持了比较成熟的SQL用户管理只要当前用户具备访问管理权限就能执行类似ALTER USER的语句。先检查当前default用户是否有访问管理权限SELECT name, access_management FROM system.users WHERE name default;如果access_management结果是1说明可以继续操作如果是0需要先在users.xml里给default加上access_management1/access_management重启后才能用SQL管理用户。具备权限之后直接执行ALTER USER default IDENTIFIED WITH sha256_password BY MyStrongPassw0rd!;这个方式的好处是不用改配置文件、不用重启服务、密码立即生效。在多节点集群里如果开启了分布式DDL还可以一条语句同步到整个集群省去逐台改配置的麻烦。不过要留意一点启用SQL用户管理之后用户信息会存在ClickHouse自己管理的系统存储里一般是/var/lib/clickhouse/access/目录不再完全依赖users.xml。如果以后想再回到纯配置文件管理得先把SQL用户删掉或者做迁移操作比单纯改users.xml要复杂一些。2.4 三种方式怎么选一张表说清楚方式是否需要重启密码存储形式适用场景安全性users.xml写明文是明文本地临时测试低users.xml写SHA256哈希是哈希单机、小规模集群生产环境中高SQL用户管理ALTER USER否哈希可指定中大规模集群、需要在线变更高3. 实操给我一台新集群我这样设置default密码3.1 动手前的准备很多人改配置之前不做备份出问题就只能手忙脚乱。我自己的习惯是改任何ClickHouse配置之前先备份原文件同时确认当前版本和服务运行状态。cp /etc/clickhouse-server/users.xml /etc/clickhouse-server/users.xml.bak.$(date %F) systemctl status clickhouse-server然后看一下当前default用户的基本信息方便改完之后对比验证clickhouse-client --query SELECT name, auth_type, host_ip, access_management FROM system.users WHERE namedefault这一步能让你心里有数修改前是什么状态修改后应该变成什么状态。3.2 方式一实操改users.xml配合SHA256哈希第一步生成密码哈希echo -n MyStrongPassw0rd! | sha256sum假设输出结果是a3f5c2b6d3e95e7f1c0a8b9d4e2f8a1b6c3d9e4f7a2b5c8d1e9f0a3b6c9d2e4f这个哈希只是示意实际操作时请用你自己生成的。第二步打开users.xmlvim /etc/clickhouse-server/users.xml在users节点下的default节点里找到或添加password_sha256_hex字段。如果原本有password字段记得删掉否则两个认证方式同时存在可能引起歧义。修改后类似这样users default password_sha256_hexa3f5c2b6d3e95e7f1c0a8b9d4e2f8a1b6c3d9e4f7a2b5c8d1e9f0a3b6c9d2e4f/password_sha256_hex networks ip::/0/ip /networks profiledefault/profile quotadefault/quota /default /users第三步重启服务让配置生效systemctl restart clickhouse-server第四步验证密码是否设置成功。不带密码登录应该失败clickhouse-client正常情况下会看到类似这样的报错Code: 516. DB::Exception: Received from localhost:9000. DB::Exception: default: Authentication failed: password is incorrect, or there is no user with such name.带正确密码登录应该成功clickhouse-client -u default --password MyStrongPassw0rd!能进命令行说明密码已经生效。3.3 方式二实操SQL在线修改不重启服务如果你的环境不方便重启但版本支持SQL用户管理那就走第二条路。第一步确认当前用户有权限SELECT name, access_management FROM system.users WHERE namedefault;如果access_management是0先临时给default加上权限。打开users.xml在default节点里加一行access_management1/access_management保存后重启一次。注意这一步需要在第一次启用SQL用户管理时重启之后就不再需要重启了。第二步修改密码ALTER USER default IDENTIFIED WITH sha256_password BY MyStrongPassw0rd!;执行完立刻生效不用重启。第三步验证SELECT name, auth_type, authentication FROM system.users WHERE namedefault;如果看到auth_type是sha256_password说明修改成功。3.4 出问题了怎么回退改密码之后连不上最直接的恢复方式就是用备份文件覆盖回去cp /etc/clickhouse-server/users.xml.bak.$(date %F) /etc/clickhouse-server/users.xml systemctl restart clickhouse-server如果你用的是SQL方式修改恢复相对麻烦一点但也有一条路子先用备份的users.xml覆盖回去并重启让default回到配置文件认证的状态再通过SQL操作把密码改回原值。总之备份文件是救命稻草千万不要跳过。4. 踩坑实录设置密码过程常见问题与排查4.1 改完密码后所有客户端连不上了这是出现频率最高的问题通常集中在几个点上。第一users.xml语法错误。XML文件标签不闭合或者字段拼写错了ClickHouse服务可能根本起不来。先看服务状态systemctl status clickhouse-server如果服务是active状态再查日志tail -n 100 /var/log/clickhouse-server/clickhouse-server.log日志里出现Config相关的报错多半就是XML格式问题认真检查标签是否配对。第二哈希值不对。确认你填到password_sha256_hex里的值就是echo -n生成的64位十六进制字符不要带空格、不要带换行。另外很多在线生成SHA256的工具默认也会带换行最好直接用命令行工具生成。第三没有真正重启服务。修改users.xml后必须重启ClickHouse否则配置不会重新加载密码自然也不会生效。第四明明配置了password却始终提示认证失败。这种情况一般是你之前通过SQL方式修改过default用户用户信息已经存在系统存储里优先级高于users.xml里的配置导致users.xml里改的东西没有生效。这时候优先用SQL方式重新设置密码或者清理掉SQL用户存储里的default记录。4.2 忘记密码了怎么找回或者重置ClickHouse不像MySQL那样有skip-grant-tables但恢复密码的原理类似通过本地文件系统把认证配置改掉重启服务。如果你还有服务器root权限操作步骤是这样的第一步备份当前users.xmlcp /etc/clickhouse-server/users.xml /etc/clickhouse-server/users.xml.bak第二步编辑users.xml把password_sha256_hex整行删掉或者临时改成空密码。如果字段不存在就保持没有密码字段的状态。default networks ip::/0/ip /networks profiledefault/profile quotadefault/quota /default第三步重启ClickHousesystemctl restart clickhouse-server第四步用空密码登录然后立刻重新设置一个强密码clickhouse-clientALTER USER default IDENTIFIED WITH sha256_password BY NewStrongPassw0rd!;这里要特别说一句临时删除密码的窗口期是非常危险的尤其是在服务器暴露在网络环境下的情况操作前最好先通过防火墙或安全组临时限制外部访问改完密码确认能登录后再放行。4.3 其他容易被忽略的细节echo -n这个坑我再强调一次少了-n哈希完全不一样。集群场景下别忘了多节点同步。如果是靠手动改users.xml那么每台机器都要改如果是SQL用户管理确认集群的分布式DDL可用否则每个节点单独执行一次。客户端、BI工具、脚本里的连接信息都要同步改。很多团队改完数据库密码第二天业务报表挂了排查半天发现是BI工具里还写着旧密码。如果ClickHouse前面还有其他代理组件比如Chproxy、ProxySQL别忘了代理到ClickHouse的连接凭证也要同步修改否则报错会非常绕一时半会儿定位不到。5. 设完密码只是第一步顺手做这几件事更稳5.1 限制default的来源IP给default设置密码之后我建议顺手把来源IP也收敛一下。默认配置里networks如果写的是ip::/0/ip那就等于允许任意IP连接密码再强也存在被暴力破解的风险。改成只允许本机和内网网段访问default password_sha256_hexa3f5c2b6d3e95e7f1c0a8b9d4e2f8a1b6c3d9e4f7a2b5c8d1e9f0a3b6c9d2e4f/password_sha256_hex networks ip127.0.0.1/ip ip10.0.0.0/8/ip ip172.16.0.0/12/ip /networks profiledefault/profile quotadefault/quota /default这样做的好处是即使密码泄露攻击者也只能从被允许的网络范围内发起连接攻击面大大缩小。5.2 收窄权限别让default处处都是“管理员”default用户虽然不一定是超级管理员但在默认配置下它通常拥有default库的所有权限包括建表、插入、修改和删除数据还能访问大部分系统表。这对日常维护来说很方便但也很危险。一旦业务账号和default混用应用出问题的时候很容易误删数据。我的建议是default只作为管理入口使用单独给业务应用创建专用账号按最小权限原则分配权限。比如CREATE USER app_user IDENTIFIED WITH sha256_password BY AppUserPassw0rd!; GRANT SELECT, INSERT ON default.* TO app_user;如果确实希望限制default本身的DDL和写操作权限也可以在users.xml里加上readonly和allow_ddl参数例如readonly1/readonly allow_ddl0/allow_ddl不过我不太建议在default上直接加只读因为它会同时限制你日常的管理操作。更好的做法是新建一个专门的管理员用户把default降级成普通只读用户这样审计和权限边界都清晰很多。5.3 更新所有接入方的连接信息最后这一步最容易遗漏。设置完default密码后原来所有通过default用户空密码连接的服务、脚本、BI工具、监控系统理论上都会断连。你需要逐个检查并更新clickhouse-client --host your-host --port 9000 --user default --password MyStrongPassw0rd!JDBC连接串jdbc:clickhouse://your-host:8123/default?userdefaultpasswordMyStrongPassw0rd!HTTP接口请求curl http://your-host:8123/?querySELECT%201 -u default:MyStrongPassw0rd!我自己的做法是改密码之前先把所有已知的接入方列一个清单改完密码之后逐个验证连通性确保没有遗漏。只有这样密码才能在不影响业务的前提下安全落地。说实话给default设置密码只是ClickHouse安全建设的第一步。我个人的习惯是装完ClickHouse第一件事就是生成一个强密码哈希填进users.xml同时在配置层面把default的来源IP收敛到本机和运维跳板机然后立刻验证一次重启后能否正常登录。后面做业务用户拆分时default基本就只作为管理入口使用日常业务都走专门的账号。这样哪怕后面忘了配置其他安全项至少不会在公网上一裸到底。设置密码这件事本身不难但选对方式、对坑有预期才能真正做到改完不慌希望这篇文章能帮你少走几步弯路。
ClickHouse默认用户安全加固：为default设置密码的三种方式与避坑指南
很多第一次部署ClickHouse的朋友估计都遇到过这样一个让我印象深刻的瞬间装好服务敲下clickhouse-client连密码都不用输直接回车就进了SQL命令行。我第一次帮同事排查ClickHouse集群时就被这个默认行为惊到了——在默认配置下default用户是没有密码的这在任何暴露的网络环境里都等于把数据库大门敞开着。今天这篇文章就围绕“给ClickHouse默认用户default设置密码”这件事把我实际用过的几种方式、在线修改与配置文件修改之间的取舍、以及生产环境里踩过的坑完整梳理一遍。刚入门的运维新人也好接手了历史遗留旧集群的老手也好这篇内容都可以直接参考照着操作。1. 为什么ClickHouse的default用户一开始是“裸奔”的1.1 默认配置下的default用户到底是什么样ClickHouse安装完成之后默认会生成一个叫default的用户这个用户从设计之初就为了“开箱即用”做了很多妥协。最典型的一点就是在/etc/clickhouse-server/users.xml这个文件里default用户段落通常只有几个关键配置项比如networks、profile、quota唯独没有密码相关的字段。我直接说结论没有密码字段就等同于空密码。也就是说在默认情况下任何能通过网络访问到ClickHouse端口的人都可以用default用户名直接登录不需要任何凭证。配合ClickHouse默认的9000端口TCP原生协议和8123端口HTTP接口只要服务器IP暴露在公网或办公网内数据被扫描和拖走只是时间问题。很多刚接触ClickHouse的人会把精力花在配置表结构、调优参数上忽略了用户认证这一层。但我的经验是用户认证和网络访问控制才是ClickHouse部署之后第一个要处理的事情。原因很简单功能再强大数据安全兜不住底后面全是麻烦。网上也时不时能看到某团队因为ClickHouse没设密码、端口暴露在公网导致数据库被恶意清空甚至被勒索的案例这类事一旦发生几乎没有后悔药。1.2 ClickHouse的认证方式有哪些怎么选ClickHouse的用户认证方式并不只有密码这一种但真正在日常运维里用得最多的基本就是以下几类password明文密码直接写在配置里简单但不安全。password_sha256_hex存储密码的SHA256哈希值配置里看不到明文推荐使用。password_double_sha256_hex存储两次SHA256后的哈希值主要用于兼容早期MySQL客户端协议场景。LDAP认证、SSL证书认证等适合企业级统一认证体系但配置复杂度高一般团队用不上。从运维角度来说我建议优先使用password_sha256_hex。原因很简单配置文件的权限管控通常没有想象中那么严格如果密码以明文形式存在users.xml里任何一个能读到服务器文件的账号都能拿到数据库密码等于设了和没设一样。而SHA256哈希即使被看到也不能直接反推出原始密码安全性高一个档次。这里还要补充一个容易被忽略的细节ClickHouse的密码哈希不是对文件或者用户名做哈希而是对“密码本身”做SHA256。所以同一个密码在任何机器上生成的哈希都是一样的这也意味着哈希一旦泄露仍然存在被暴力破解或撞库的风险因此密码本身的强度依然很重要。2. 设置default密码的三种主流方式2.1 最直观的方式在users.xml里直接写明文密码很多教程第一步就会带你打开/etc/clickhouse-server/users.xml然后在default节点下加一行default passwordMyStrongPassw0rd!/password networks ip::/0/ip /networks profiledefault/profile quotadefault/quota /default这种方式改起来最快重启ClickHouse服务后密码立刻生效。我用“最直观”来形容它是因为它的逻辑一眼就能看懂不需要生成任何哈希也不涉及额外的命令。但它的缺点同样明显。第一密码明文出现在配置文件里服务器上其他账号只要能读这个文件就能拿到密码第二很多团队会把配置文件提交到Git仓库或者内部文档系统里明文密码很容易在不知不觉中泄露出去第三一旦有人截图或者复制了配置文件的内容发到聊天工具里密码就成了“公开的秘密”。所以我个人很少在生产环境用明文方式最多就是在本地临时测试环境图省事用一下。2.2 我推荐的方式在users.xml里写入SHA256哈希既然不推荐明文那生产环境怎么搞我的习惯是先把密码用SHA256算法做一次哈希再把哈希值写进users.xml。具体生成命令很简单echo -n MyStrongPassw0rd! | sha256sum这里必须强调一下echo -n的-n参数不能丢。如果漏了-n字符串后面会带一个换行符算出来的哈希跟不带换行符的哈希完全是两个值而且这种错误肉眼几乎看不出来。我之前就见过同事配置完之后怎么都登录不上折腾了半天才发现是echo命令漏了-n。拿到哈希之后把它填到users.xml里default password_sha256_hex5e884898da28047151d0e56f8dc6292773603d0d6aabbdd62a11ef721d1542d8/password_sha256_hex networks ip::/0/ip /networks profiledefault/profile quotadefault/quota /default修改完保存然后重启ClickHouse服务密码就会按SHA256方式校验。我个人在实际生产环境里基本都是用这种方式因为它既不牺牲安全性也不需要额外维护一套用户管理组件对单机或小规模集群来说性价比最高。2.3 更灵活的方式用SQL用户管理在线修改如果你的ClickHouse版本在21.x以上还有一种更省事的方式直接用SQL语句在线修改用户密码不需要重启服务。ClickHouse从较新版本开始支持了比较成熟的SQL用户管理只要当前用户具备访问管理权限就能执行类似ALTER USER的语句。先检查当前default用户是否有访问管理权限SELECT name, access_management FROM system.users WHERE name default;如果access_management结果是1说明可以继续操作如果是0需要先在users.xml里给default加上access_management1/access_management重启后才能用SQL管理用户。具备权限之后直接执行ALTER USER default IDENTIFIED WITH sha256_password BY MyStrongPassw0rd!;这个方式的好处是不用改配置文件、不用重启服务、密码立即生效。在多节点集群里如果开启了分布式DDL还可以一条语句同步到整个集群省去逐台改配置的麻烦。不过要留意一点启用SQL用户管理之后用户信息会存在ClickHouse自己管理的系统存储里一般是/var/lib/clickhouse/access/目录不再完全依赖users.xml。如果以后想再回到纯配置文件管理得先把SQL用户删掉或者做迁移操作比单纯改users.xml要复杂一些。2.4 三种方式怎么选一张表说清楚方式是否需要重启密码存储形式适用场景安全性users.xml写明文是明文本地临时测试低users.xml写SHA256哈希是哈希单机、小规模集群生产环境中高SQL用户管理ALTER USER否哈希可指定中大规模集群、需要在线变更高3. 实操给我一台新集群我这样设置default密码3.1 动手前的准备很多人改配置之前不做备份出问题就只能手忙脚乱。我自己的习惯是改任何ClickHouse配置之前先备份原文件同时确认当前版本和服务运行状态。cp /etc/clickhouse-server/users.xml /etc/clickhouse-server/users.xml.bak.$(date %F) systemctl status clickhouse-server然后看一下当前default用户的基本信息方便改完之后对比验证clickhouse-client --query SELECT name, auth_type, host_ip, access_management FROM system.users WHERE namedefault这一步能让你心里有数修改前是什么状态修改后应该变成什么状态。3.2 方式一实操改users.xml配合SHA256哈希第一步生成密码哈希echo -n MyStrongPassw0rd! | sha256sum假设输出结果是a3f5c2b6d3e95e7f1c0a8b9d4e2f8a1b6c3d9e4f7a2b5c8d1e9f0a3b6c9d2e4f这个哈希只是示意实际操作时请用你自己生成的。第二步打开users.xmlvim /etc/clickhouse-server/users.xml在users节点下的default节点里找到或添加password_sha256_hex字段。如果原本有password字段记得删掉否则两个认证方式同时存在可能引起歧义。修改后类似这样users default password_sha256_hexa3f5c2b6d3e95e7f1c0a8b9d4e2f8a1b6c3d9e4f7a2b5c8d1e9f0a3b6c9d2e4f/password_sha256_hex networks ip::/0/ip /networks profiledefault/profile quotadefault/quota /default /users第三步重启服务让配置生效systemctl restart clickhouse-server第四步验证密码是否设置成功。不带密码登录应该失败clickhouse-client正常情况下会看到类似这样的报错Code: 516. DB::Exception: Received from localhost:9000. DB::Exception: default: Authentication failed: password is incorrect, or there is no user with such name.带正确密码登录应该成功clickhouse-client -u default --password MyStrongPassw0rd!能进命令行说明密码已经生效。3.3 方式二实操SQL在线修改不重启服务如果你的环境不方便重启但版本支持SQL用户管理那就走第二条路。第一步确认当前用户有权限SELECT name, access_management FROM system.users WHERE namedefault;如果access_management是0先临时给default加上权限。打开users.xml在default节点里加一行access_management1/access_management保存后重启一次。注意这一步需要在第一次启用SQL用户管理时重启之后就不再需要重启了。第二步修改密码ALTER USER default IDENTIFIED WITH sha256_password BY MyStrongPassw0rd!;执行完立刻生效不用重启。第三步验证SELECT name, auth_type, authentication FROM system.users WHERE namedefault;如果看到auth_type是sha256_password说明修改成功。3.4 出问题了怎么回退改密码之后连不上最直接的恢复方式就是用备份文件覆盖回去cp /etc/clickhouse-server/users.xml.bak.$(date %F) /etc/clickhouse-server/users.xml systemctl restart clickhouse-server如果你用的是SQL方式修改恢复相对麻烦一点但也有一条路子先用备份的users.xml覆盖回去并重启让default回到配置文件认证的状态再通过SQL操作把密码改回原值。总之备份文件是救命稻草千万不要跳过。4. 踩坑实录设置密码过程常见问题与排查4.1 改完密码后所有客户端连不上了这是出现频率最高的问题通常集中在几个点上。第一users.xml语法错误。XML文件标签不闭合或者字段拼写错了ClickHouse服务可能根本起不来。先看服务状态systemctl status clickhouse-server如果服务是active状态再查日志tail -n 100 /var/log/clickhouse-server/clickhouse-server.log日志里出现Config相关的报错多半就是XML格式问题认真检查标签是否配对。第二哈希值不对。确认你填到password_sha256_hex里的值就是echo -n生成的64位十六进制字符不要带空格、不要带换行。另外很多在线生成SHA256的工具默认也会带换行最好直接用命令行工具生成。第三没有真正重启服务。修改users.xml后必须重启ClickHouse否则配置不会重新加载密码自然也不会生效。第四明明配置了password却始终提示认证失败。这种情况一般是你之前通过SQL方式修改过default用户用户信息已经存在系统存储里优先级高于users.xml里的配置导致users.xml里改的东西没有生效。这时候优先用SQL方式重新设置密码或者清理掉SQL用户存储里的default记录。4.2 忘记密码了怎么找回或者重置ClickHouse不像MySQL那样有skip-grant-tables但恢复密码的原理类似通过本地文件系统把认证配置改掉重启服务。如果你还有服务器root权限操作步骤是这样的第一步备份当前users.xmlcp /etc/clickhouse-server/users.xml /etc/clickhouse-server/users.xml.bak第二步编辑users.xml把password_sha256_hex整行删掉或者临时改成空密码。如果字段不存在就保持没有密码字段的状态。default networks ip::/0/ip /networks profiledefault/profile quotadefault/quota /default第三步重启ClickHousesystemctl restart clickhouse-server第四步用空密码登录然后立刻重新设置一个强密码clickhouse-clientALTER USER default IDENTIFIED WITH sha256_password BY NewStrongPassw0rd!;这里要特别说一句临时删除密码的窗口期是非常危险的尤其是在服务器暴露在网络环境下的情况操作前最好先通过防火墙或安全组临时限制外部访问改完密码确认能登录后再放行。4.3 其他容易被忽略的细节echo -n这个坑我再强调一次少了-n哈希完全不一样。集群场景下别忘了多节点同步。如果是靠手动改users.xml那么每台机器都要改如果是SQL用户管理确认集群的分布式DDL可用否则每个节点单独执行一次。客户端、BI工具、脚本里的连接信息都要同步改。很多团队改完数据库密码第二天业务报表挂了排查半天发现是BI工具里还写着旧密码。如果ClickHouse前面还有其他代理组件比如Chproxy、ProxySQL别忘了代理到ClickHouse的连接凭证也要同步修改否则报错会非常绕一时半会儿定位不到。5. 设完密码只是第一步顺手做这几件事更稳5.1 限制default的来源IP给default设置密码之后我建议顺手把来源IP也收敛一下。默认配置里networks如果写的是ip::/0/ip那就等于允许任意IP连接密码再强也存在被暴力破解的风险。改成只允许本机和内网网段访问default password_sha256_hexa3f5c2b6d3e95e7f1c0a8b9d4e2f8a1b6c3d9e4f7a2b5c8d1e9f0a3b6c9d2e4f/password_sha256_hex networks ip127.0.0.1/ip ip10.0.0.0/8/ip ip172.16.0.0/12/ip /networks profiledefault/profile quotadefault/quota /default这样做的好处是即使密码泄露攻击者也只能从被允许的网络范围内发起连接攻击面大大缩小。5.2 收窄权限别让default处处都是“管理员”default用户虽然不一定是超级管理员但在默认配置下它通常拥有default库的所有权限包括建表、插入、修改和删除数据还能访问大部分系统表。这对日常维护来说很方便但也很危险。一旦业务账号和default混用应用出问题的时候很容易误删数据。我的建议是default只作为管理入口使用单独给业务应用创建专用账号按最小权限原则分配权限。比如CREATE USER app_user IDENTIFIED WITH sha256_password BY AppUserPassw0rd!; GRANT SELECT, INSERT ON default.* TO app_user;如果确实希望限制default本身的DDL和写操作权限也可以在users.xml里加上readonly和allow_ddl参数例如readonly1/readonly allow_ddl0/allow_ddl不过我不太建议在default上直接加只读因为它会同时限制你日常的管理操作。更好的做法是新建一个专门的管理员用户把default降级成普通只读用户这样审计和权限边界都清晰很多。5.3 更新所有接入方的连接信息最后这一步最容易遗漏。设置完default密码后原来所有通过default用户空密码连接的服务、脚本、BI工具、监控系统理论上都会断连。你需要逐个检查并更新clickhouse-client --host your-host --port 9000 --user default --password MyStrongPassw0rd!JDBC连接串jdbc:clickhouse://your-host:8123/default?userdefaultpasswordMyStrongPassw0rd!HTTP接口请求curl http://your-host:8123/?querySELECT%201 -u default:MyStrongPassw0rd!我自己的做法是改密码之前先把所有已知的接入方列一个清单改完密码之后逐个验证连通性确保没有遗漏。只有这样密码才能在不影响业务的前提下安全落地。说实话给default设置密码只是ClickHouse安全建设的第一步。我个人的习惯是装完ClickHouse第一件事就是生成一个强密码哈希填进users.xml同时在配置层面把default的来源IP收敛到本机和运维跳板机然后立刻验证一次重启后能否正常登录。后面做业务用户拆分时default基本就只作为管理入口使用日常业务都走专门的账号。这样哪怕后面忘了配置其他安全项至少不会在公网上一裸到底。设置密码这件事本身不难但选对方式、对坑有预期才能真正做到改完不慌希望这篇文章能帮你少走几步弯路。
