Utility to scan for unpassworded SSH privkeys?

[Nico Kadel-Garcia]

On May 24, 2013, at 23:02, Nico Kadel-Garcia <nkadel at gmail.com> wrote:

> 
> 
> On May 24, 2013, at 8:47, Stephen Frost <sfrost at snowman.net> wrote:
> 
>> * Nico Kadel-Garcia (nkadel at gmail.com) wrote:
>>> 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.
>> 
>> ... it doesn't?  Why not?  Having a .k5login for the 'git' account is
>> essentially the same as having an authorized_keys file for the same
>> account..  I've not looked into it specifically, but the offhand comment
>> above surprised me, so I'm curious what the specific issue there is.
> 
> This is the problem. Many people who've not actually tried it think "oh, that's easy, I'll just stitch together these bits I know".

Sorry, got cut off. I did not mean to snark at you, but to explain it's far more awkward in practice.  In this case, there seems not to be a good way with Kerberos to do a "forced command" to tie specific user authentication for subversion or git, to tie user specific authentication to a specific .klogin listed account. The result for Subversion is that all changes would be logged as coming from the common "svn" user. For git it gets a bit weirder due to "merge' operations and "pull requests" run on the server. But pull requests on the server will all be owned by the common "git" user with .klogin, and change  tracking winds up in la-la land as it would for Subversion.

It remains much easier to manage with the "gitosis" or "gitolite"similar SSH key management tools, that use different "forced commands" for each user for git. There is no published equivalent for Subversion, sadly.


>> (I'm also a fan of encouraging Kerberos utilization whenever possible)

Good! I've pursued this before and not gotten far due to the missing "forced command" feature.