On 5 April 2016 at 14:32, Nathan Ward <nw...@daork.net> wrote: Hey,
> I agree with you that putting these in the config is probably a solution - > though, backing them up to a RANCID server or whatever might not be ideal? > Not too sure, I’d have to think some more about this. I’d also be worried > about people using the same host key on many routers because they copied the > whole config over. By no means perfect solution, few are But easily deployable today without changes to processes or people and immediate security benefits. > Thinking of other solutions, can the router report in to a management system > and drop off it’s public key I wonder - perhaps the outbound-ssh service > could help establish the initial comms if you have the ability to get a > trusted, common config on to your boxes. I don’t know if outbound-ssh lets > you get a non-netconf SSH connection back in, and I’m not exactly sure of > what the mechanics would be of all that anyway.. it might make it worse. I'm thinking that if some protocol (probably not SSH, but does not matter now) could refresh devices publickey in central location and this protocol would rely on constant/static credentials in configuration templates, then it seem like ultimately it is same solution as just storing secret key in configs? Anyone with access to configs can update publickey to match newly generated secret key? Perhaps if all devices would have something like Cisco CMP (ETH OOB), which would add some identity in as DHCP option, and you could query from Cisco via RESTFUL HTTPS with this hash secret+identity+customerID+orderID if it's device Cisco shipped you and what is the CMP device's initial ssh fingerprint. Then you could programmatically give lease, if HTTPS proves success, programmatically with ssh push keys to the actual management plane. Secret would have been previously set on Cisco order pages. Something to that note might work. But would take long to deploy, would take forever to be ubiquitous. Where as secret in config is trivially implementable by all vendors rapidly. I know I could produce that DHCP server in working day, but how many organisation could not? > What happens in an RE failover if you’ve got a master only address? Does each > RE have it’s own key? I haven’t been the person on the ground for one of > those for years so can’t remember! REs maintain same key. -- ++ytti _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp