openssh unix dev - May 2013 - Utility to scan for unpassworded SSH privkeys?

I like to retain some semblance of optimism for humanity, and so I'm just
going to hope that this assertion is false. I have to hope that there is at
least a large minority of people who correctly use ssh-agent for the suppression
of password prompting, and protect their private keys with passwords.?

-------- Original message --------
From: Dan Kaminsky <dan at doxpara.com> 
Date: 05/23/2013  5:39 PM  (GMT-08:00) 
To: "Dan Mahoney, System Admin" <danm at prime.gushi.org> 
Cc: openssh-unix-dev at mindrot.org 
Subject: Re: Utility to scan for unpassworded SSH privkeys? 
 
Effectively nobody passphrases their ssh keys.? They're used as a way to
*suppress* password entry in the real world -- use this, and things just work
rather than poking you each time.

Sent from my iPhone

On May 23, 2013, at 5:19 PM, "Dan Mahoney, System Admin" <danm at
prime.gushi.org> wrote:
> Hey all,
> 
> Let's make an assumption:
> 
> 1) I am a root user on a system.
> 
> 2) I don't want said system being used as a jumping-off point if either
a user account or the root account is compromised.
> 
> Given an unencrypted private key, plus a known_hosts file, plus
bash_history, it's a pretty easy avenue of attack once you're in the
front door.? And it's happened before*.
> 
> Thus, what I'd like to do is (in the spirit of crack's
"nastygram" script), trawl through user .ssh directories and warn
users with insecure keys (or warn root).
> 
> I'm shocked I can't find something that does this with a basic
google search.? Debian offers their ssh-vulnkey tool, but that checks for
something different (weak RNG-seeded keys).
> 
> Has anyone come across something like this?? Better still, written it?
> 
> It seems to me that something like this should be in /contrib, but
that's just me.
> 
> My ears are open.
> 
> -Dan
> 
>
*(http://it.slashdot.org/story/12/11/17/143219/freebsd-project-discloses-security-breach-via-stolen-ssh-key)
> http://threatpost.com/apache-site-hacked-through-ssh-key-compromise-082809/
> 
> -- 
> 
> --------Dan Mahoney--------
> Techie,? Sysadmin,? WebGeek
> Gushi on efnet/undernet IRC
> ICQ: 13735144?? AIM: LarpGM
> Site:? http://www.gushi.org
> ---------------------------
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev at mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Thu, May 23, 2013 at 8:23 PM, Jamie Beverly <jamie.beverly at
yahoo.com> wrote:
> I like to retain some semblance of optimism for humanity, and so I'm
just going to hope that this assertion is false. I have to hope that there is at
least a large minority of people who correctly use ssh-agent for the suppression
of password prompting, and protect their private keys with passwords.
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.

My repeated surveys of environments with NFS home directories show
that at least 10% often far more, of SSH keys are not protected. And
the people who are worst about their passphrase keys tend to be admins
who "know better" and who follow the common security model of "if
you
don't trust the machine you're on, you shouldn't be working on
it",
and therefore refuse to follow even the most basic security practices.

It's a big reason that I encourage migration to Kerberos based
authentication wherever possible, but that doesn't work well for
Subversion or git authentication.