On Thu, Nov 12, 2020 at 11:44 AM Angus Clarke <angus(a)charworth.com> wrote:
Righto
For sure the ssh-copy-id is not happy either - in 20something years I've never used
this before, I've always just manipulated files.
I did start raising a bug ... missed some field, had to click back and lost all the
previously inputted information - I forgot about this ...
Overall, tracing the issue is the thing that took too long, there was some message in the
hosted-engine-deployment logs (one of the logs from the engine VM itself) which said
something like "check you ssh host keys" (sorry, I've lost that information
now) - it would have been useful to see it say something about editing the file
/root/.ssh/authorized_keys on the KVM host prior to this.
I didn't spend too long debugging the kvm-add-host-to-cluster issue - I didn't
find too much in the way of obvious errors in logs on the 2nd KVM host for that either;
rather - having just realised and resolved the hosted-engine deployment issue - I guessed
the same response to the add-kvm-host to cluster issue which resolved that too.
So maybe a bit of extra logging on the matter would be a great way forwards, or with such
few use cases (am I really the only one to manipulate AuthorizedKeysFile? - wow!) then no
action at all might be appropriate.
If you still have the logs, please file a bug and attach them, and
perhaps point out what you'd expect there that is missing (or just let
us look at them, and if we decide that the information there is
enough, we'll ask you, after finding the most relevant line).
Generally speaking, and assuming your only problem was in "Add host to
engine" flow (specifically also during hosted-engine deploy), you
should find these logs in the _engine_ machine, in
/var/log/ovirt-engine (and subdirs). The deploy process also tries to
copy these logs to the _host_, under
/var/log/ovirt-hosted-engine-setup, and this part was enhanced
somewhat in 4.4.3 (see
https://bugzilla.redhat.com/1844965 ).
Best regards,
Cheers
Angus
# ls .ssh
ls: cannot access .ssh: No such file or directory
# ssh-copy-id server2
/usr/bin/ssh-copy-id: ERROR: failed to open ID file '/root/.pub': No such file or
directory
(to install the contents of '/root/.pub' anyway, look at the -f option)
________________________________
From: Martin Perina <mperina(a)redhat.com>
Sent: 12 November 2020 09:43
To: Angus Clarke <angus(a)charworth.com>
Cc: users(a)ovirt.org <users(a)ovirt.org>; Dana Elfassy <delfassy(a)redhat.com>;
Yedidyah Bar David <didi(a)redhat.com>
Subject: Re: [ovirt-users] sshd_config AuthorizedKeysFile
Hi,
could you please try if ssh-copy-id works with your non-standard sshd configuration?
Because last time I've checked I haven't noticed that behavior and keys were
always added to $HOME/.ssh/authorized_keys
So feel free to create a bug for that, but up until now you are the first user using this
non-standard configuration ...
Regards,
Martin
On Thu, Nov 12, 2020 at 9:00 AM Angus Clarke <angus(a)charworth.com> wrote:
Hello
Sharing for anyone who needs it, this was carried out on OL7, they use ovirt 4.3
In short: both the hosted-engine deployment routine and the host add to cluster routine
distribute public ssh keys to /root/.ssh/authorized_keys regardless of the
AuthorizedKeysFile setting in /etc/ssh/sshd_config. Both routines fail if
AuthorizedKeysfile is not default.
The hosted-engine setup assumes AuthorizedKeysFile to be default (~/.ssh/authorized_keys)
and creates a public key there, instead of following the sshd_config directive. The setup
fails on the back of this.
Once I commented this out of sshd_config file (assumes default) and restarted sshd on the
KVM host that was running the hosted-engine deployment, the hosted-engine setup completed
successfully.
Similarly, I could not deploy a second KVM host to the compute cluster until I had
altered this setting on that 2nd KVM host - presumably that process has some similar
routine that unwittingly writes keys to ~/.ssh/authorized_keys.
HTH
Angus
_______________________________________________
Users mailing list -- users(a)ovirt.org
To unsubscribe send an email to users-leave(a)ovirt.org
Privacy Statement:
https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/UMJ4Y622RAL...
--
Martin Perina
Manager, Software Engineering
Red Hat Czech s.r.o.
--
Didi