On 5 Apr 2016, at 14:14 EAT, Saku Ytti wrote:
On 5 April 2016 at 13:52, Richard Hartmann
<richih.mailingl...@gmail.com> wrote:
This still sounds as if your CMDB would need to detect that, raise a
flag, and then push out new config after being updated; in case of
planned maintenance, you could even add that info before the swap.
I don't think you can push secret key, not in supported way at least.
You can jump to shell and replace the host keys in unixy way, of
course. But how do you jump to the box when you don't know its keys?
If you do know, then there is no point jumping to replace them, innit?
If you want to do this right today, the correct way is to extract
public key in secure manner (What is secure? OOB not really, but maybe
human on-site) and store them in your jump box for user-wide
consumption, and raise alarm if host keys have changed. So who ever is
physically installing RE, should also make sure hostkeys are updated
securely in centralised location.
I personally take an event that changes the host key the same as having
a new host (irrespective of platform). Usually those events have a human
doing the changes in the similar way that deploying a new one would.
I therefore apply the same policy I would as if it was new kit. Tedious
I know, but SSH wasn’t really designed to make it easy to verify keys
via third parties.
I’ve currently taken to maintaining SSHFP DNS records (rfc4255) and
this seems to work pretty well for me (in signed zones of course).
--
patrick
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
