On Wed, Oct 20, 2010 at 4:13 AM, Michael Starks <[email protected]> wrote: > On 10/19/2010 07:33 PM, Kacper Wysocki wrote: >> Transferring the key in the clear really breaks the security of the >> system. > > True. > >> Suppose instead that you distribute some command ssh client through >> Bigfix (such as rsync for windows) along with a pre-generated ssh key. >> >> Then you could extract the client.key from the server directly, then >> delete the ssh key in the Bigfix script immediately after copy so that >> it's not stored on every client. >> After mass deployment one could even revoke the ssh key on the server. >> >> Disclaimer: I haven't tried this (yet) but I'd be interested in >> hearing about how it makes out. > > It's an interesting idea, and one I have thought about myself. You have > solved the problem of clear-text transmission, but you still have what > amounts to pretty standard authentication. Get a copy of one SSH key and you > have read access to all OSSEC keys.
That's just it, if you still end up serving the ssh key in the clear this scheme amounts to nothing but obfuscation. However, if you manage to distribute the 1 key securely to N hosts then you've solved the problem which was to avoid the overhead of manually distributing N keys to N hosts. In the linux client case one would simply create a server-side ssh keypair. Then we'd distribute the public key, manually or through the configuration engine, but we do this anyway to manage the clients. Then setting up a new client becomes a simple script the push of client keys from the server. > I thought about having a copy of the keys parsed by a PHP script and served > up by an SSL-protected web page. The script could parse the correct key > based on the source IP of the host, while the web server could require a > client certificate for authentication. At least that way you would have > machine-level authentication and encryption, and each machine would only get > its own key. This, too, is not without risks, but I think it covers the main > areas of concern. Not to knock your scheme which may well be more secure, but it doesn't avoid the original problem: you'll now have to create and distribute N client certificates somehow. Maybe you have a functional PKI infrastructure already and this is not a problem for you? Otherwise one might as well try to distribute the original client.key somehow without the added complexity. I was thinking in the same lines though: if you place the (ssh or client) keys on a crypted share (ssh, HTTP/ssl or the such) with IP-based ACLs in place then you're relying on your client IP's. That may or may not be a problem, depending on how much you trust your network layer, whether you have 802.1x NAC or some other way of ensuring there are no bogons. 0K
