Hello! On Sat, 2014-02-01 at 09:43 +0100, Prunk Dump wrote:
> It's true that there is no 100% secure way to send passwords to > clients ! But SSH key are very secure and they are greatly sufficient > for my network. That was not my point. What I was trying to say was, that if you can not physically trust your network (eg you are installing workstations in computer classrooms where in principle a student can plug in his own computer), then you can not keep any information delivered during the FAI install secret either. Think of it this way: you start with bare hardware with no pre-installed secrets. Any keys or passwords need to be delivered via the network (to get the premise of "fully automatic", "no human intervention needed" install). And thus the intruder also has access to these secrets. Let me elaborate this via an extreme example. The intruder (eg the clever student at the classroom) can configure his PC (or a virtual machine inside it) to look exactly like the workstation you are going to install. This includes MAC address, disk size, etc. Now he can install a "private copy" of the workstation, and get all the secrets you would have sent to the real workstation over the network. Later at home he breaks into the system (because it is his hardware, it will always be possible), learns the secrets and, depending on their nature, may get unauthorized access to your servers or other resources. In real life, depending on how you planned to send the secrets, the intruder probably will not need to perform a full install. It may be a lot easier to harvest the secrets from the install server via NFS, SVN, cfengine, or other similar mechanisms by faking a computer being installed, or possibly by simply querying the appropriate servers. Which brings us back to the original point: if you need to operate on such open networks, your need to resort to out-of-band delivery of the secrets (at least a master key/password to access the rest), such as use of USB stick, typing in a password, ssh'ing into the host during install (which involves manual check of the hosts' identity) etc. Alternatively, use timing-and-logging based approaches: the secret is available for a limited time, and/or any access to the secret is logged and possibly reported, so you at least know when someone stole the key. Regards, Toomas Tamm