[j-nsp] protect ssh and telnet

[Saku Ytti]

On 5 April 2016 at 14:32, Nathan Ward <nward at 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