Utility to scan for unpassworded SSH privkeys?

Nico Kadel-Garcia nkadel at gmail.com
Sun May 26 08:29:13 EST 2013


On Sat, May 25, 2013 at 6:03 PM, Dan Mahoney <danm at prime.gushi.org> wrote:
> Responses inline.
>
> On May 25, 2013, at 8:06, Nico Kadel-Garcia <nkadel at gmail.com> wrote:
>
>> On Sat, May 25, 2013 at 7:33 AM, Damien Miller <djm at mindrot.org> wrote:
>>> On Sat, 25 May 2013, Nico Kadel-Garcia wrote:
>>>
>>> Scanning for passwordless keys on a filesystem is fortunately very
>>> simple, and does have a real benefit.
>>
>> Except that it can't scan filesystems on people's disconnected
>> laptops, or their local machines that they propage their keys from but
>> are in the backup system, nor does it scale well for large
>> environments, nor environments that use NFSv4 with Kerberized access,
>> nor environments that auto-mount home directories, nor does it
>> eliminate the old keys from the backup system, etc., etc. And note
>> that a file system scan is next to useless for auto-mounted home
>> directories in most NFS automount configurations, since the wildcard
>> based mounting of home directories provides no direct hint of what the
>> mountpoints might be.
>
> I'm pretty sure I can run over my NFS server with "find" and "exec" and do what I need to, for any number of users.  Which is kind of what any potential person to compromise the system will do anyway.

This works only if you have good command access to the NFS server
itself. In EMC or NetApp or many larger environments, an admin running
a security probe only *rarely* has such access.

>> You get the idea. It's possible for users who are being cunning
>
> ...interesting term considering the problem I initially posited (users being ignorant).  Being both cunning and ignorant is a rare occurrence.  Or at least I used to think.  I've been proven wrong before.

It's an incredible education problem.

> On the other hand, If you manage to have my machine be an attack vector, because your unencrypted key on your compromised/stolen laptop agent-forwarded through my system, I'll probably forgive you.  And be impressed.

Through yours? The risk would be mostly if I'm also an admin on your
system. And shared admin environments are quite common in large
conputing environments, and in univiersities and research
environments.


> For what it's worth, I'm not against a patch-set that enables ssh-keygen to NOT generate a passwordless key, period.  (If you generate one elsewhere and upload it, I can't really help that, but I can scan for it).  I'm not even against a patch-set that runs it through some sorts of quality-meters (cracklib?  Is that still a thing?)
>
> On a more evil side, it would be cool if sshd could look for key-based logins that are happening too quickly (indicating no password is being typed), but which do not also attempt to forward an agent -- yes, it's still possible ssh-agent is being used, and just not forwarding, but that's half the point of the agent.  There's a possible research paper there for someone, most likely.

That.... oooohhh, i *like* it. Not necessarily fail, but simply
sending a message to syslog would be helpful for security auditing. It
would need to be optional: there are setups like git and Subversion
where ssh-agent shouldn't really be forwarded. And forwarding is off
by default in ssh_config, so it's of limited use in default
environments.

> At any rate, I've found what I'm interested in.  When I get something nice written up, I may offer it up to stick in /contrib, because I feel such a thing is important.  At the very least, I'll push it to a blog.
>
> All the best.
>
> -Dan

If you can bundle it nicely, how about posting it to github.com ?


More information about the openssh-unix-dev mailing list