[j-nsp] protect ssh and telnet

[Patrick Okui]

On 5 Apr 2016, at 14:14 EAT, Saku Ytti wrote:

> On 5 April 2016 at 13:52, Richard Hartmann 
> <richih.mailinglist at 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