企业官网建设流程全解析

很多第一次部署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> <password>MyStrongPassw0rd!</password> <networks> <ip>::/0</ip> </networks> <profile>default</profile> <quota>default</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_hex>5e884898da28047151d0e56f8dc6292773603d0d6aabbdd62a11ef721d1542d8</password_sha256_hex> <networks> <ip>::/0</ip> </networks> <profile>default</profile> <quota>default</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_management>1</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 三种方式怎么选，一张表说清楚

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 name='default'"

这一步能让你心里有数，修改前是什么状态，修改后应该变成什么状态。

3.2 方式一实操：改users.xml配合SHA256哈希

第一步，生成密码哈希：

echo -n 'MyStrongPassw0rd!' | sha256sum

假设输出结果是a3f5c2b6d3e95e7f1c0a8b9d4e2f8a1b6c3d9e4f7a2b5c8d1e9f0a3b6c9d2e4f，这个哈希只是示意，实际操作时请用你自己生成的。

第二步，打开users.xml：

vim /etc/clickhouse-server/users.xml

在<users>节点下的<default>节点里，找到或添加<password_sha256_hex>字段。如果原本有<password>字段，记得删掉，否则两个认证方式同时存在可能引起歧义。修改后类似这样：

<users> <default> <password_sha256_hex>a3f5c2b6d3e95e7f1c0a8b9d4e2f8a1b6c3d9e4f7a2b5c8d1e9f0a3b6c9d2e4f</password_sha256_hex> <networks> <ip>::/0</ip> </networks> <profile>default</profile> <quota>default</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 name='default';

如果access_management是0，先临时给default加上权限。打开users.xml，在<default>节点里加一行：

<access_management>1</access_management>

保存后重启一次。注意，这一步需要在第一次启用SQL用户管理时重启，之后就不再需要重启了。

第二步，修改密码：

ALTER USER default IDENTIFIED WITH sha256_password BY 'MyStrongPassw0rd!';

执行完立刻生效，不用重启。

第三步，验证：

SELECT name, auth_type, authentication FROM system.users WHERE name='default';

如果看到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.xml：

cp /etc/clickhouse-server/users.xml /etc/clickhouse-server/users.xml.bak

第二步，编辑users.xml，把<password_sha256_hex>整行删掉，或者临时改成空密码。如果字段不存在，就保持没有密码字段的状态。

<default> <networks> <ip>::/0</ip> </networks> <profile>default</profile> <quota>default</quota> </default>

第三步，重启ClickHouse：

systemctl restart clickhouse-server

第四步，用空密码登录，然后立刻重新设置一个强密码：

clickhouse-client

ALTER 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_hex>a3f5c2b6d3e95e7f1c0a8b9d4e2f8a1b6c3d9e4f7a2b5c8d1e9f0a3b6c9d2e4f</password_sha256_hex> <networks> <ip>127.0.0.1</ip> <ip>10.0.0.0/8</ip> <ip>172.16.0.0/12</ip> </networks> <profile>default</profile> <quota>default</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>参数，例如：

<readonly>1</readonly> <allow_ddl>0</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?user=default&password=MyStrongPassw0rd!

HTTP接口请求：

curl 'http://your-host:8123/?query=SELECT%201' -u 'default:MyStrongPassw0rd!'

我自己的做法是，改密码之前先把所有已知的接入方列一个清单，改完密码之后逐个验证连通性，确保没有遗漏。只有这样，密码才能在不影响业务的前提下安全落地。

说实话，给default设置密码只是ClickHouse安全建设的第一步。我个人的习惯是：装完ClickHouse第一件事就是生成一个强密码哈希填进users.xml，同时在配置层面把default的来源IP收敛到本机和运维跳板机，然后立刻验证一次重启后能否正常登录。后面做业务用户拆分时，default基本就只作为管理入口使用，日常业务都走专门的账号。这样哪怕后面忘了配置其他安全项，至少不会在公网上一裸到底。设置密码这件事本身不难，但选对方式、对坑有预期，才能真正做到改完不慌，希望这篇文章能帮你少走几步弯路。