Xscontainer
-
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.