crmsh has issue with the default ed25519 ssh key

[liangxin1300]

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]

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]

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]

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]

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

• crm cluster init/join should work well with ed25519 key pair
• avoid the hard code of rsa key type

Let's focus on a small scope and keep improving