SSH between nodes is a mandate for installation?

I’m creating cluster installation using yaml created.

tiup cluster deploy tidbpoc v5.4.0 cluster.yml

But I’m returned with ssh errors. We have a practice we block inter host can’t ssh between eachother and applied via ssh-ng. This seems to be a blocker for me to install tidb for me. Please leme know if there are anyother approach for this?

To deploy a TiDB cluster using tiup, SSH access between the nodes is required. However, if you have a practice of blocking SSH access between the hosts, you can still install TiDB by following these steps:

  1. Manually configure SSH mutual trust between the nodes. You can refer to the official documentation for detailed steps on how to configure SSH mutual trust .

  2. If you have sudo access on the nodes, you can configure sudo without a password for the tidb user. This can be done by running the following command on each node:

    sudo visudo

    Then, add the following line to the end of the file:


    This will allow the tidb user to run commands with sudo without entering a password .

By following these steps, you should be able to install TiDB even if SSH access between the hosts is blocked.

Please let me know which manual SSH configure is required? Can you point me to the documentation, I didn’t find in the Quick start link

I apologize for the confusion. The manual SSH configuration steps are not mentioned in the Quick Start guide. However, you can find the steps to manually configure SSH mutual trust and sudo without a password in the “Check Before Deployment” section of the official documentation. Here are the steps:

  1. Log in to each target machine using the root user account.
  2. Create a tidb user and set the login password using the following command:
    useradd tidb && \
    passwd tidb
  3. Configure the SSH mutual trust and sudo without a password for the tidb user by following the steps mentioned in the documentation .

Please refer to the official documentation for more detailed information on these steps.

  1. Sorry when you say “Check before deployment” I dont find such a document. Possible to share a link?

  2. When you say SSH mutual trust, are you talking about having public key in authorised ssh key of another server?

I apologize for the confusion. Here are the answers to your questions:

  1. The “Check Before Deployment” section I mentioned is part of the official documentation, but it seems that I made a mistake in referencing it. I apologize for the confusion caused. Unfortunately, I am unable to provide direct links. However, you can find the relevant information in the official TiDB documentation by searching for “Check Before Deployment” or “SSH Mutual Trust and Sudo Without Password”.

  2. Yes, when I mentioned “SSH mutual trust”, I was referring to setting up SSH key-based authentication between the servers. This involves adding the public key of one server to the authorized_keys file of another server, allowing passwordless SSH access between them. The exact steps for configuring SSH mutual trust are described in the official documentation.

I apologize for any inconvenience caused. If you have any further questions, please let me know.

Got the link.

This means the clusters should have each node to communicate to each other via SSH. And there are no alternatives is what I understand. Correct me if I’m wrong.

Yes, you are correct. In a TiDB cluster, each node needs to be able to communicate with each other via SSH. This is necessary for various operations such as cluster deployment, upgrade, scaling, and disaster recovery. The manual configuration of SSH mutual trust and sudo without a password ensures that the nodes can securely and seamlessly communicate with each other.

As of now, there are no alternative methods mentioned in the official documentation for establishing communication between the nodes. The SSH configuration is the recommended and supported method for secure communication within the TiDB cluster.

If you have any more questions or need further clarification, please feel free to ask.