search

ClusterLabs / crmsh

Command-line interface for High-Availability cluster management on GNU/Linux systems.
GNU General Public License v2.0
131 stars 94 forks source link

crmsh has issue with the default ed25519 ssh key #1504

Open liangxin1300 opened 3 months ago

liangxin1300 commented 3 months ago

When the init node already generated ssh key(default kind is ed25519), join node will failed:

INFO: Configuring SSH passwordless with root@alp-1
DEBUG: su_subprocess_run: ['/bin/sh', '-c', "ssh-copy-id -i ~/.ssh/id_rsa.pub 'root@alp-1' &> /dev/null"], {}
ERROR: cluster.join: Failed to login to root@alp-1. Please check the credentials.
Traceback (most recent call last):
  File "/usr/lib/python3.11/site-packages/crmsh/ui_context.py", line 93, in run
    rv = self.execute_command() is not False
         ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/crmsh/ui_context.py", line 276, in execute_command
    rv = self.command_info.function(*arglist)
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/crmsh/ui_cluster.py", line 520, in do_join
    bootstrap.bootstrap_join(join_context)
  File "/usr/lib/python3.11/site-packages/crmsh/bootstrap.py", line 2314, in bootstrap_join
    join_ssh(cluster_node, remote_user)
  File "/usr/lib/python3.11/site-packages/crmsh/bootstrap.py", line 1602, in join_ssh
    return join_ssh_impl(local_user, seed_host, seed_user, keys)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/crmsh/bootstrap.py", line 1624, in join_ssh_impl
    raise ValueError(msg)
ValueError: Failed to login to root@alp-1. Please check the credentials.

It seems we have lots of places hard-coded as id_rsa.pub

liangxin1300 commented 2 months ago

Above comment seems can't reproduce now

But there does exist another issue: When the init node and join node are already setup passwordless with the ed25519 key, then after bootstrap init/join process, there is still a key pair generated on the init node

liangxin1300 commented 1 week ago

Steps to reproduce:

  1. on the first node without any ssh key, generate ed25519 key
  2. on the second node without any ssh key, generate ed25519 key
  3. on the first node, run crm cluster init -y
  4. on the second node, join to the first node, got 
    # crm cluster join -c alp-1 -y
INFO: Configuring SSH passwordless with root@alp-1
ERROR: cluster.join: Failed to login to root@alp-1. Please check the credentials.
    INFO: Configuring SSH passwordless with root@alp-1
DEBUG: su_subprocess_run: ['/bin/sh', '-c', "ssh-copy-id -i ~/.ssh/id_rsa.pub 'root@alp-1' &> /dev/null"], env={'SSH_AUTH_SOCK': ''}, {}
ERROR: cluster.join: Failed to login to root@alp-1. Please check the credentials.
Traceback (most recent call last):
File "/usr/lib/python3.11/site-packages/crmsh/ui_context.py", line 93, in run
rv = self.execute_command() is not False
     ^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.11/site-packages/crmsh/ui_context.py", line 278, in execute_command
rv = self.command_info.function(*arglist)
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.11/site-packages/crmsh/ui_cluster.py", line 503, in do_join
bootstrap.bootstrap_join(join_context)
File "/usr/lib/python3.11/site-packages/crmsh/bootstrap.py", line 2288, in bootstrap_join
join_ssh(cluster_node, remote_user)
File "/usr/lib/python3.11/site-packages/crmsh/bootstrap.py", line 1588, in join_ssh
return join_ssh_impl(local_user, seed_host, seed_user, keys)
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.11/site-packages/crmsh/bootstrap.py", line 1610, in join_ssh_impl
raise ValueError(msg)
ValueError: Failed to login to root@alp-1. Please check the credentials.
nicholasyang2022 commented 1 week ago

We'd better handle this as a new feature and define the use cases clearly. For example,

  1. What is the preferred key type when initialize a new cluster and there is not any existing private keys?
  2. If some private keys existing, what key types are acceptable? (For example, DSA keys are considered unsafe now and maybe we should not use it even if there is an existing one.)
  3. Should we support using keys with different types on different nodes?
  4. If a new type of key pair is generated after the cluster is bootstrapped, will our code work properly?
liangxin1300 commented 1 week ago

We'd better handle this as a new feature and define the use cases clearly. For example,

  1. What is the preferred key type when initialize a new cluster and there is not any existing private keys?
  2. If some private keys existing, what key types are acceptable? (For example, DSA keys are considered unsafe now and maybe we should not use it even if there is an existing one.)
  3. Should we support using keys with different types on different nodes?
  4. If a new type of key pair is generated after the cluster is bootstrapped, will our code work properly?

I think we can first address the above issue I said: the new distribution like Tumbleweed using ed25519 key by default

Let's focus on a small scope and keep improving