Re: [SAGE] The danger of SSH keys..

[Richard Chycoski <rskiadmin@chycoski.com>]

Yes - passphrases associated with a specific command (rather than an open 
shell) and with the private keys stored on properly controlled machines are an 
example where passwordless keys can be an acceptable security risk for many 
environments.

It all depends on your security needs, the environment in which the keys are 
being stored, and the medium across which the data is being transported.

With properly secured endpoints I do not have a problem with passwordless keys 
in a controlled environment. This is better than a weak password - it takes a 
lot more work (and computing power) to attack a system that has a passwordless 
SSH key (assuming a reasonably large key size - a few years ago RSA was 
recommending at least a 2048 bit key, I haven't heard if they have increased 
that recommendation lately) than to crack an even reasonably crafted system 
password. (And users have ways of crafting passwords that satisfy most 
rulesets but are still crackable.) And I've never seen someone write down 
their SSH private key and leave it attached to the their monitor. (:-)

However, if the private key is stored on a personal laptop that can be lost or 
stolen, I'm more concerned. If you have that kind of security problem then 
disallow the use of keys and start requiring two-factor authentication, 
preferably with a hardware token. You can also strengthen this by using 
encrypted filesystems and stronger access methods for the laptops, but this 
can be difficult to implement and enforce in many organisations unless 
mandated by law.

Somewhere in the middle is a grey area - do you trust passwordless keys from 
desktops (non-portable systems) that are located on your intranet? SSH 
keyagents can help, but can also create more loopholes than passwordless keys.

You have to evaluate the level of security that you need against the risk of 
being compromised and apply it to your own environment.

- Richard


Neil Watson wrote:
> There are times when there is a legitimate reason for using a key with
> no pass-phrase.  Globally restricting this may cause a problem even as
> it solves another.
>