How to Use Security Authentication Method to Deploy TiDB Cluster with TiUP

Translated
1

Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.

Original topic: 使用TiUP部署 TiDB 集群，如何使用安全认证方式

| username: TiDBer_新手

[TiDB Usage Environment] Single machine with multiple instances simulating a production environment, the company does not provide the root password
[TiDB Version] v7.5.0
[Reproduction Path] Operations performed that led to the issue:

  1. Connected using ssh 192.168.36.61, the user on 192.168.36.61 is deployer, without sudo permissions and without the root password.
    Following the documentation to deploy a TiDB cluster with TiUP on a single machine with multiple instances, at step 4: executing the deployment command
    tiup cluster check ./topology.yaml --user root
    did not use a secure authentication method. The documentation mentions two authentication methods but does not clarify how to generate them.
    The documentation states that cluster deployment via TiUP can use either a key or an interactive password for secure authentication:
    If using a key, you can specify the key path with -i or --identity_file. How is this key generated?
    If using a password, you can enter the password interactively with -p. How is this SSH Password generated?

[Encountered Issue: Problem Phenomenon and Impact]
When executing the command, the log shows the following error. Based on personal guess, it roughly means that when connecting ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain. Unable to authenticate 192.168.36.61.
2024-02-02T17:05:09.862+0800 INFO Execute command finished {“code”: 1, “error”: “failed to fetch cpu-arch or kernel-name: executor.ssh.execute_failed: Failed to execute command over SSH for ‘root@192.168.36.61:22’ {ssh_stderr: , ssh_stdout: , ssh_command: export LANG=C; PATH=$PATH:/bin:/sbin:/usr/bin:/usr/sbin uname -m}, cause: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain”, “errorVerbose”: “executor.ssh.execute_failed: Failed to execute command over SSH for ‘root@192.168.36.61:22’ {ssh_stderr: , ssh_stdout: , ssh_command: export LANG=C; PATH=$PATH:/bin:/sbin:/usr/bin:/usr/sbin uname -m}, cause: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain\n at github.com/pingcap/tiup/pkg/cluster/executor.(*EasySSHExecutor).Execute()\n\tgithub.com/pingcap/tiup/pkg/cluster/executor/ssh.go:174\n at github.com/pingcap/tiup/pkg/cluster/executor.(*CheckPointExecutor).Execute()\n\tgithub.com/pingcap/tiup/pkg/cluster/executor/checkpoint.go:86\n at github.com/pingcap/tiup/pkg/cluster/task.(*Shell).Execute()\n\tgithub.com/pingcap/tiup/pkg/cluster/task/shell.go:43\n at github.com/pingcap/tiup/pkg/cluster/task.(*Serial).Execute()\n\tgithub.com/pingcap/tiup/pkg/cluster/task/task.go:86\n at github.com/pingcap/tiup/pkg/cluster/task.(*StepDisplay).Execute()\n\tgithub.com/pingcap/tiup/pkg/cluster/task/step.go:111\n at github.com/pingcap/tiup/pkg/cluster/task.(*Parallel).Execute.func1()\n\tgithub.com/pingcap/tiup/pkg/cluster/task/task.go:144\n at runtime.goexit()\n\truntime/asm_amd64.s:1650\ngithub.com/pingcap/errors.AddStack\n\tgithub.com/pingcap/errors@v0.11.5-0.20201126102027-b0a155152ca3/errors.go:174\ngithub.com/pingcap/errors.Trace\n\tgithub.com/pingcap/errors@v0.11.5-0.20201126102027-b0a155152ca3/juju_adaptor.go:15\ngithub.com/pingcap/tiup/pkg/cluster/task.(*Shell).Execute\n\tgithub.com/pingcap/tiup/pkg/cluster/task/shell.go:50\ngithub.com/pingcap/tiup/pkg/cluster/task.(*Serial).Execute\n\tgithub.com/pingcap/tiup/pkg/cluster/task/task.go:86\ngithub.com/pingcap/tiup/pkg/cluster/task.(*StepDisplay).Execute\n\tgithub.com/pingcap/tiup/pkg/cluster/task/step.go:111\ngithub.com/pingcap/tiup/pkg/cluster/task.(*Parallel).Execute.func1\n\tgithub.com/pingcap/tiup/pkg/cluster/task/task.go:144\nruntime.goexit\n\truntime/asm_amd64.s:1650\nfailed to fetch cpu-arch or kernel-name”}

After specifying the root account and password with -p, using the command tiup cluster check ./topology.yaml --apply --user k8soperator -p to execute the check, it was found that the mounted directory does not support the nodelalloc parameter
does not have ‘nodelalloc’ option set, auto fixing not supported. How can this be resolved?
[deployer@k8s-node2 tidb]$ tiup cluster check ./topology.yaml --apply --user k8soperator -p
tiup is checking updates for component cluster …
Starting component cluster: /home/deployer/.tiup/components/cluster/v1.14.1/tiup-cluster check ./topology.yaml --apply --user k8soperator -p
Input SSH password:

  • Detect CPU Arch Name

    • Detecting node 192.168.36.61 Arch info … Done

  • Detect CPU OS Name

    • Detecting node 192.168.36.61 OS info … Done

  • Download necessary tools

    • Downloading check tools for linux/amd64 … Done

  • Collect basic system information

  • Collect basic system information

    • Getting system info of 192.168.36.61:22 … Done

  • Check time zone

    • Checking node 192.168.36.61 … Done

  • Check system requirements

  • Check system requirements

  • Check system requirements

  • Check system requirements

    • Checking node 192.168.36.61 … Done
    • Checking node 192.168.36.61 … Done
    • Checking node 192.168.36.61 … Done
    • Checking node 192.168.36.61 … Done
    • Checking node 192.168.36.61 … Done
    • Checking node 192.168.36.61 … Done
    • Checking node 192.168.36.61 … Done
    • Checking node 192.168.36.61 … Done
    • Checking node 192.168.36.61 … Done
    • Checking node 192.168.36.61 … Done
    • Checking node 192.168.36.61 … Done
    • Checking node 192.168.36.61 … Done
    • Checking node 192.168.36.61 … Done

  • Cleanup check files

    • Cleanup check files on 192.168.36.61:22 … Done
      Node Check Result Message

192.168.36.61 cpu-cores Pass number of CPU cores / threads: 4
192.168.36.61 cpu-governor Warn Unable to determine current CPU frequency governor policy, auto fixing not supported
192.168.36.61 disk Fail mount point /cubd/tidb1 does not have ‘nodelalloc’ option set, auto fixing not supported
192.168.36.61 disk Fail mount point /cubd/tidb4 does not have ‘nodelalloc’ option set, auto fixing not supported
192.168.36.61 thp Pass THP is disabled
192.168.36.61 command Pass numactl: policy: default
192.168.36.61 os-version Pass OS is CentOS Linux 7 (Core) 7.9.2009
192.168.36.61 memory Pass memory size is 16384MB
192.168.36.61 network Pass network speed of cali180eff2222a is 10000MB
192.168.36.61 network Pass network speed of cali3b166e8a736 is 10000MB
192.168.36.61 disk Warn mount point / does not have ‘noatime’ option set, auto fixing not supported
192.168.36.61 disk Warn mount point /cubd/tidb1 does not have ‘noatime’ option set, auto fixing not supported
192.168.36.61 disk Warn mount point /cubd/tidb4 does not have ‘noatime’ option set, auto fixing not supported
192.168.36.61 selinux Pass SELinux is disabled

[Resource Configuration] Enter TiDB Dashboard - Cluster Info - Hosts and screenshot this page

fstab
fstab698×324 9.21 KB

Configuration File
Configuration File815×525 16.8 KB

fstab
fstab698×324 9.21 KB

[Attachments: Screenshots/Logs/Monitoring]

2
| username: 小龙虾爱大龙虾 | Original post link

The password to be entered is the root password, and the root passwords of all machines where components are to be deployed need to be consistent. If you use a key to log in, you need to configure passwordless SSH access from the TiUP machine to the machines to be deployed. You can generate this using the ssh-keygen command. You can search online for detailed instructions.

3
| username: tidb菜鸟一只 | Original post link

Without sudo permissions and root password, you cannot deploy the cluster. You can use tiup playground v7.5.0 --host 0.0.0.0 to create a single-machine test environment for an experience.

4
| username: zhanggame1 | Original post link

It’s very simple: tiup cluster check ./topology.yaml --user root -p

Just add -p to input the root password, making sure all machines have the same root password, and then you won’t have to mess around with permissions.

5
| username: seiang | Original post link

For a production environment, it is recommended to create a tidb user, ensuring that the tidb user is the same across all nodes. Then, use the tidb user for deployment. When deploying with tiup, add the -p parameter. Example: tiup cluster check ./topology.yaml --user tidb -p

6
| username: zhanggame1 | Original post link

There’s no need for that. Just use tiup with --user root to install. As long as your YAML file specifies that TiDB should run with the tidb user, the installation script will automatically create it. Manually creating it is unnecessary and cumbersome when you have many servers.

7
| username: seiang | Original post link

What you said is correct, but many company DBAs do not have root user login permissions.

8
| username: zhanggame1 | Original post link

Install it and use it occasionally, but not regularly.

9
| username: Kongdom | Original post link

:thinking: For multiple instances on a single machine, mutual trust should also be established, right? It’s been a long time since I deployed, but I feel that the new version should also require mutual trust.

10
| username: kkpeter | Original post link

Mark, waiting for the solution :index_pointing_at_the_viewer:

11
| username: dba远航 | Original post link

This installation requires root privileges.

12
| username: TiDBer_新手 | Original post link

I have already used tiup playground to experience it and it works, but when connecting through my own Windows computer’s Go and Python APIs to perform CRUD operations, I still disabled SSL. When SSL is set to true, errors still occur.

13
| username: tidb菜鸟一只 | Original post link

Have you enabled TLS? 为 TiDB 客户端服务端间通信开启加密传输 | PingCAP 文档中心

14
| username: TiDBer_新手 | Original post link

TLS is not enabled.

15
| username: tidb菜鸟一只 | Original post link

If I understand correctly, you are connecting to the TiDB server through a program, right? Then wouldn’t you need to enable TLS on it and connect via SSL?

16
| username: TiDBer_新手 | Original post link

Yes, TLS needs to be enabled.

17
| username: TiDBer_新手 | Original post link

I asked a colleague for the root password and was able to log in directly.

18
| username: zhanggame1 | Original post link

Use root once for deployment, then generally don’t use it. The tidb user is automatically created, you just need to change the password yourself.

19
| username: TiDBer_5Vo9nD1u | Original post link

Adding to the whitelist is better.

20
| username: TiDBer_新手 | Original post link

The cluster has started normally, but auto-tls=false, and TLS is not enabled. The client USE_SSL=‘false’. This kind of cluster with TLS disabled can be used normally, right? Are there any disadvantages? The answer on Tongyi Qianwen says it is not secure, but I understand that the cluster can still be used as usual.

Answer on Tongyi Qianwen:
If TLS (Transport Layer Security) encryption is not enabled in the TiDB cluster, the following impacts will exist:

  1. Data Transmission Security Risks: Without TLS, communication between TiDB services and clients will not be encrypted. This means all data transmitted over the network (including but not limited to database login credentials, query statements, and returned result sets) will be transmitted in plaintext, making it easy to be intercepted by network sniffing or man-in-the-middle attacks.
  2. Compliance Issues: For organizations that need to meet specific security standards and regulations, not enabling TLS may not comply with data protection and privacy requirements, such as GDPR, which requires encryption of sensitive data during transmission.
  3. Lack of Trust Chain: Enabling TLS can establish a server identity authentication mechanism, allowing clients to verify the certificate to confirm that they are connecting to the correct server. Without TLS, this cannot be guaranteed.
  4. Reduced Security: Enabling TLS can effectively prevent replay attacks, data tampering, and other security threats. Without it, these security measures are missing.

In summary, in a production environment, to ensure the security and data integrity of the database system, it is strongly recommended to enable TLS encryption.

This is my first time configuring a TiDB cluster in the company. Previously, the MySQL service I used did not enable SSL. I thought of configuring it the same way as the previous MySQL service, without configuring TLS. I wonder if there will be any functional limitations in using the TiDB cluster.