Utility to scan for unpassworded SSH privkeys?

[Phil Pennock]

On 2013-05-24 at 23:32 -0400, Nico Kadel-Garcia wrote:
> 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.

I use Kerberised Subversion and have done since 2006.  The identifier
that appears in "svn log" etc is my kerberos identity, with realm
intact.

I don't use the SSH transport to do so; https with Apache, the normal
Subversion modules and mod_auth_kerb, pointing Krb5Keytab at a keytab
with credentials for Apache; be sure to enable KrbMethodNegotiate.

The client uses ra_neon which will happily use Kerberos, *provided* that
you're on https not http.  The ra_neon module doesn't do auth-layer
wrap/unwrap, so Kerberos-negotiated protection layers from GSSAPI will
break, so the client code hard-disables the WWW-Authenticate negotiate
mechanism if only http.

In the AuthzSVNAccessFile config, I define things like:

  [groups]
  foo = foo, foo at SPODHUIS.ORG

and then use "@foo" for access controls where before I might have used
just "foo".

I prefer git these days, but do miss the Kerberised access.  If I were
going to invest time in setting it up, I'd add OpenSSH on a non-standard
port, configure a ForceCommand in the system-wide sshd_config for that
sshd and then enable Kerberos an auth mechanism for that.  Add a
hostname alias such as "kgit.example.org" and tell folks to add to
~/.ssh/config a block which sets Port for that hostname, so that nobody
has to mess around trying to pass port specifications down through git
command invocations and instead it comes via ssh(1) using a hostname
alias.  Heck, kgit doesn't need to exist in DNS if folks use Hostname in
their ssh_config, but it eases debugging and support burden if it does
exist.

For myself, I'd avoid even that Port messing around and do for kgit
exactly what I do for svn: dedicated IPv6 address, so that
forward/reverse DNS can match exactly and the service is only accessible
over IPv6.  These days, that's not a problematic constraint.

-Phil