Utility to scan for unpassworded SSH privkeys?

[Jamie Beverly]

I could be mistaken, but I think Damien was referring to the difficulty of attempting to require encryption on, and passphrases for keys. Regardless of what defaults keygen has, a user could easily decrypt the key, and store it insecurely. Not that this is okay, but that you can only enforce that a key is stored securely at the client, which you can never really trust. So you are always at the mercy of users doing the right thing. It's roughly the same issue as people putting passwords on post-it notes.



Sent from my Verizon Wireless 4G LTE Smartphone

-------- Original message --------
From: Nico Kadel-Garcia <nkadel at gmail.com> 
Date: 05/24/2013  10:33 PM  (GMT-08:00) 
To: Damien Miller <djm at mindrot.org> 
Cc: Jamie Beverly <jamie.beverly at yahoo.com>,Dan Kaminsky <dan at doxpara.com>,"Dan Mahoney, System Admin" <danm at prime.gushi.org>,openssh-unix-dev at mindrot.org 
Subject: Re: Utility to scan for unpassworded SSH privkeys? 
 
On Sat, May 25, 2013 at 12:36 AM, Damien Miller <djm at mindrot.org> wrote:
> On Fri, 24 May 2013, Nico Kadel-Garcia wrote:
>
>> This is not a new flaw. It dates right back to the original SSH-1 and
>> SSH-2, which were forked to create OpenSSH. It's also why the highly
>> vaunted security of OpenBSD is fairly pointless, when such gaping
>> configuration holes are the *default* configuration. ssh-keygen
>> creates passphrase frees by default if you simply hit "Enter" a few
>> times, and there is no way I've ever seen for ssh_config to reject
>> them by default when loading local keys or loading them into an
>> ssh-agent.
>
> If you think it through, what you are asking for is basically impossible
> outside of a hugely restricted enviornment (trivial evasion: upload a
> custom ssh client that ignores your proposed restriction), and if you
> happen to have a hugely restricted environment then you don't need it
> to begin with.

Damien, I'm sorry, but this is *precisely* the "if you don't trust
your environment, you shouldn't be using it" attitude that leads to
grossly dangerous default security practices. It's the approach that
leads to people having passphrase keys, by default. Even when someone
has a secure local physical environment, I find they often model
exactly this behavior for people in much less secure environments who
have not been better educated. It's also still a dangerous approach
for "secure" environments because the passphrase keys are on the local
disk, on shared home directories, on backups, or on rooted systems.
And I've encountered far, far, far too many admins who use passphrase
free keys for remote access to *other* systems, including allegedly
"secure" exposed external servers, without bothering with any of the
filtering necessary to restrict such risks.

I even keep catching Linux and yes, OpenBSD "architects" doing this
kind of "keep passphrase free root keys to remote servers lying
around"  in NFS accessible homedirs, portable computes, backup tapes,
and even sent via email. I've caught roughly..... 20 system admins
doing this in the last couple of years, including entire *departments*
who "trust the people the work with" and can't be bothered to protect
their keys in NFS based envornments, and are *never educated* by their
system architects.

The attitude of "if I can break your window, you shouldn't be even
bothered to lock your car" is an unfortunately common one in the
security world. Security can be strongly improved by using layers:
improving the defaults to use a m ore secure behavior is a simple
step, much as an occasional audit of SSH keys in $HOME/.ssh/ in NFS or
other shared environments is invaluable.