Xscontainer
-
@stormi Hello, I don't really see how to solve the ssh problem or even solve the problem with python.
-
If I understand correctly:
- your root user in XCP-ng has a SSH key that was generated by the script
- this key was added to the authorized_keys file for your user in the VM
- this should allow root on XCP-ng to login with ssh without a password, but this doesn't
So: try to login with ssh, without password, outside the script. Add one or more
-v
switches to SSH. Check the web for similar issues. -
@stormi Hi, I just tested and it still doesn't work
-
Can you be more specific?
-
@olivierlambert I still have the same problem, even adding the ssh keys before running xscontainer.
-
Have you followed the details given by @stormi ? You should have some detailed output then
-
@olivierlambert I have this output :
[13:24 xcp-ng-XXXX ~]# ssh -v XXX@XXXXXXXXX OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 58: Applying options for * debug1: Connecting to XXXXXXXX [XXXXXXXX] port 22. debug1: Connection established. debug1: permanently_set_uid: 0/0 debug1: key_load_public: No such file or directory debug1: identity file /root/.ssh/id_rsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /root/.ssh/id_rsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /root/.ssh/id_dsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /root/.ssh/id_dsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /root/.ssh/id_ecdsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /root/.ssh/id_ecdsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /root/.ssh/id_ed25519 type -1 debug1: key_load_public: No such file or directory debug1: identity file /root/.ssh/id_ed25519-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_7.4 debug1: Remote protocol version 2.0, remote software version OpenSSH_8.7 debug1: match: OpenSSH_8.7 pat OpenSSH* compat 0x04000000 debug1: Authenticating to XXXXXXXXX:22 as 'XXXXXXXX' debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: algorithm: curve25519-sha256 debug1: kex: host key algorithm: ecdsa-sha2-nistp256 debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha2-256 compression: none debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha2-256 compression: none debug1: kex: curve25519-sha256 need=32 dh_need=32 debug1: kex: curve25519-sha256 need=32 dh_need=32 debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ecdsa-sha2-nistp256 SHA256:bmXWosoos6FqfYJXXYPv1H5lU4fRKIucvEv1QE/chN0 debug1: Host 'XXXXXXXXXXXX' is known and matches the ECDSA host key. debug1: Found key in /root/.ssh/known_hosts:1 debug1: rekey after 4294967296 blocks debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: rekey after 4294967296 blocks debug1: SSH2_MSG_EXT_INFO received debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,sk-ssh-ed25519@openssh.com,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256@openssh.com,webauthn-sk-ecdsa-sha2-nistp256@openssh.com> debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password debug1: Next authentication method: gssapi-keyex debug1: No valid Key exchange context debug1: Next authentication method: gssapi-with-mic debug1: Unspecified GSS failure. Minor code may provide more information No Kerberos credentials available (default cache: KEYRING:persistent:0) debug1: Unspecified GSS failure. Minor code may provide more information No Kerberos credentials available (default cache: KEYRING:persistent:0) debug1: Next authentication method: publickey debug1: Trying private key: /root/.ssh/id_rsa debug1: Trying private key: /root/.ssh/id_dsa debug1: Trying private key: /root/.ssh/id_ecdsa debug1: Trying private key: /root/.ssh/id_ed25519 debug1: Next authentication method: password XXXXX@XXXXXXXXX's password: debug1: Authentication succeeded (password). Authenticated to XXXXXXXXXXXX ([XXXXXXXXXX]:22). debug1: channel 0: new [client-session] debug1: Requesting no-more-sessions@openssh.com debug1: Entering interactive session. debug1: pledge: network debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0 debug1: Sending environment. debug1: Sending env LANG = fr_FR.UTF-8 Last login: Mon Jan 23 13:23:33 2023 [XXXXX@docker ~]$
-
-
Can you check the presence of the key inside your VM?
-
@olivierlambert yes
Output to docker machine :
[XXXX@docker ~]$ cat .ssh/authorized_keys ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDkaRRvfWs0qPggPY2VW8/4n3DcjDbZPKM8w7FS418CCZn+8JvB1LNmR1vJXHr7F4k73bo/aIDQ3Lh09iWZOhYwA1nkeDwNyBexVDYiPCuA1DEbiaFuFvo+fMB5rkb9n5WucWuGCkGgwJCB/iEbQni3k0neJe6m3SzHPUJ7DYDu5agzaBjfe0eGn9NyMindLwA/0aNl5TbwYJoxvU1HSCuDXSlcPwg5xEAqs+Rx/0LBdGlu4LiAR/K/187vPRLL3mNFzlGS1peVirqAOOJjSAg0FkQFcqGW5QRNaaAuh9eYy31FCwWC+o4+qpiy/EM0yaBn9gMlBxYxxbaJW8nzJR6zZ1w7xp7fvpdPyxzFxSAYoKIgqrGGKalbTgj25yj5odrTuhvbrzv3Jlfys6RI6SGITeVWNTHT4UtODu5+EKlCQT5UG4jEAwg9Dib68zZjxmJeTBV+Kwk7hd1i2CPkAuWT6oA477qou+ezFMkvBvlphQzGfF4h2cvU81KDvmCoCl5uySGwaQytWXHocnAUusQTUXvz1poPljPXngP3TKuJuaq0QuKKddhZvm4gRe00MzQSifrqfog6bBnDyGk5nhDjEtfd8kuusmjEp+n5+0p4l2+yZxud2eia3CEIHxCusJcKRivqccPp5uOw0kOVyeTd0KOrFRhDFljckowacGF2wQ== root@xcp-ng-XXX [XXXX@docker ~]$
Output to XCP machine :
[07:53 xcp-ng-XXXX ~]# cat .ssh/known_hosts 192.XXX.XXX.XXX ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBNJxGOt3RvDXvelRUPTYyIHmykXhfRWSEN6PXSKYUVxct8qjENHqqqAEJOrl6E5cF9orOGQfbAPjSlLwNqGUGlo= [07:55 xcp-ng-XXX ~]#
-
One or more added
-v
to ssh might tell why the keys are not accepted. -
@kiu I reproduced your issue.
The issue comes from a lib used by
xscontainer
as a SSH Client which use a deprecated algossh-rsa
so all modern (>=8.7) OpenSSH reject the connexion. -
@BenjiReis following: I tested on a Centos7 VM with an older openssh and the prepare VM script was successful.
-
So, we found the reason: xscontainer in XCP-ng currently uses a rather old version of python2-paramiko, which seems to insist on using
ssh-rsa
algorithms, support for which was dropped in recent openssh releases.That's why it works for some distros and not for others.
We'll see it to update the components. Meanwhile, it's possible to fix it by installing python2-pip from EPEL and then upgrading first to "cryptography < 2.6" and then to "paramiko < 3". However, doing this as root may overwrite the files from the RPMs so it's not really clean. I'd advise it only for testing.
-
@stormi OK, thanks. I will try your solution on a small lab.
-
@stormi I tried to do it but I don't think I succeeded. Could you send me a more specific doc of what you are doing?
thanks
-
UPDATE 2024-03-19: DON'T DO THIS. We won't support any XCP-ng hosts where system packages have been overriden with pip.
I think these are the steps that worked for me:
yum install xscontainer yum install python2-pip --enablerepo=epel pip2 install --upgrade "pip < 21" pip2 install --upgrade "cryptography == 2.5" pip2 install --upgrade "paramiko < 3"
As this is done outside a virtualenv (I've tried inside a virtualenv, but I think xscontainer runs stuff outside of it, so it didn't work), this will overwrite the contents of RPMs you installed, so, again, only for testing.
I also had to remove the former host key from the VM metadata:
xe vm-param-remove uuid=... param-name=other-config param-key=xscontainer-sshhostkey
-
@stormi Thanks, I just tried that and it still doesn't work
-
Well, I tried it myself on a freshly installed pool, and this worked. Can you elaborate on what doesn't work?
-
@stormi I still have the same problem, the key does not want to install and asks me if I want to try again.