[ovirt-users] Error during hosted-engine-setup for 3.5.1 on F20 (Cannot add the host to cluster ... SSH has failed)

[Simone Tiraboschi]

----- Original Message -----
> From: "Sven Kieske" <s.kieske at mittwald.de>
> To: "Simone Tiraboschi" <stirabos at redhat.com>
> Cc: users at ovirt.org
> Sent: Tuesday, March 10, 2015 11:12:38 AM
> Subject: Re: [ovirt-users] Error during hosted-engine-setup for 3.5.1 on F20 (Cannot add the host to cluster ... SSH
> has failed)
> 
> 
> 
> On 10/03/15 10:53, Simone Tiraboschi wrote:
> > In order to trust an https connection to the engine you have
> > to trust its CA but you still don't know it cause it's a
> > private one and it has been just created on the engine from scratch.
> 
> Can't the setup display the necessary parameters to make
> sure I trust the right CA when I accept it in my browser?
> It could even create a consumable file, which I can copy
> to my workstation and import there.

This is another things: having the user explicitly trusting the CA cert by manually and explicitly checking its fingerprint on both the host is the right solution but is more invasive and a lot of user is already complaining that hosted-engine involves to many steps. 


> > Blindly downloading the engine CA cert and blindly trusting it is not
> > that different that simply using http to download the public key:
> 
> this is correct, but who would do this?
> of course you need to check if it is the right CA!
> 
> > in order to fetch it you don't need to send any password
> > or token and being a public key you don't need to crypt
> > it by definition so you don't need encryption.
> 
> this is not about keeping the public key secret, but
> about keeping the channel over which it is transferred
> secure. so no one can tamper with the key and send
> you another public key to a different machine.
> (dns spoofing, arp spoofing etc.)
> 
> if you don't check the public key and ensure you
> connect to the correct machine, there is no need
> for public keys anyway and you could just skip this
> step.
> 
> imho this is a security bug.
> other people would just consider this a hardening.
> trusting the local network is a security mindset
> from the 90's.

No, I didn't said that I trust the network to be secure cause it's a local network.
I said another thing, please read it carefully and follow me:
1. in order to trust an https connection you need to trust the CA that signed the cert that the engine host is using.
2. that CA is by default a private CA and so it has just been created on engine VM, so you don't have the CA cert on the host
3. so, to trust the https connection, you need to have/download the CA cert from the engine VM to the host
4. if you just download engine CA via http (https is not more secure at this point cause you are still trusting everything cause you don't have the CA cert) you just moved the issue instead of solving it

So the issue is that the CA cert should reach the host in secure way otherwise you are in the same situation: somebody could provide a tampered CA cert and make you trusting a tampered https connection. It's just false security: it simply adds complexity without adding real security.
I would be different if we ask to the user to copy and paste the engine CA cert by himself or at least to validate its fingerprint, without that step its really the same. 


> most LANs have to many hosts which you might
> don't even know.
> 
> you could also be on some shared foreign network
> where third party machines from different users
> can tamper with the network.
> I have seen user reports who used some
> leased hardware in offsite data centers to install
> ovirt, where you can't fully trust all local clients.
> 
> this should be more secure by default imho.



> --
> Mit freundlichen Grüßen / Regards
> 
> Sven Kieske
> 
> Systemadministrator
> Mittwald CM Service GmbH & Co. KG
> Königsberger Straße 6
> 32339 Espelkamp
> T: +49-5772-293-100
> F: +49-5772-293-333
> https://www.mittwald.de
> Geschäftsführer: Robert Meyer
> St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
> Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
>