On 5 April 2016 at 19:18, Tore Anderson <[email protected]> wrote: Hey,
> Speaking only for myself, I'd accept server key change only if it's a > device that is known to have been recently replaced/zeroized/etc. I'd > *never* accept a key changing without that being expected for some > reason known in advance. Depending on scale of network and position in the organisation this may work. But if network has 100 tacacs account, thousands or tens of thousands of devices, it may not be realistic to expect everyone of the 100 user has good grasp when device is being replaced. Maybe 5 of those even understand what SSH keys mean. I think secret-in-config is fast remedy to hard problem. People who are able to do something smart should be able to disable it, but it seems safest default way to work. But it might be too late now for that, as everyone has learned to ignore keys and many people have toolised the key verification out. > That's not really true even if you blindly accept any changed/unknown > SSH key, because telnet will leak information like login credentials in > cleartext to any passive listener while mounting a successful attack on > SSH requires MitM capability. That's more difficult to pull off. Also, > if you're using SSH keys your login credentials won't leak even if you > are successfully MitMed. I don't really have statistics on how often you are able to passively listen but not inject, but logically it does make sense that passive listen is more common, but by which margin, I don't know. From security point of view I consider SSH Telnet equal when SSH keys are not verified. But I still prefer SSH in this scenario, because it's easier to mechanise with SSH via exec() channels etc. -- ++ytti _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
