Comment 2 for bug 1010582

Revision history for this message
Scott Moser (smoser) wrote : Re: [Bug 1010582] Re: Log imported user ssh key fingerprints

On Fri, 17 Aug 2012, Joshua Harlow wrote:

> So for this I am thinking of a new config module that has the following
> config.
>
> display_ssh_fingerprints:
> - bob
> - /homes/harlowja/.ssh/id_rsa.pub
> ...
>
> This would also by default add in the "user:" key in config if it exists
> to the above list.
>
> What would occur is that if the 'name' above is a file the 'ssh-keygen
> -lf' command will be ran on it and outputed with the filename where it
> can from
>
> If not a file then there will be some searching to see if we can find
> that users ssh public key (rsa or dsa, or both). If not found, warn,
> otherwise print it with the user. If nothing provided then show no ssh
> keys imported/configured.

The thing we're interested in is ~/.ssh/authorized_keys.
That is what is read by sshd to determine if the user can get in or not.
Unfortunately, it seems that ssh-keygen only lists the *first* entry in
that file if you do:
 ssh-keygen -lf ~/.ssh/authorized_keys
which is insufficient if we're interested in logging all the keys that can
get in.

You'll probably be best off using something in the 'ssh_util.py' as there
are 2 tricky issues with doing what we want:
 a.) the AuthorizedKeys line is not the same format as a id_rsa.pub file
     although somehow ssh-keygen seems to be OK with the difference, but
     it still only reads one line.
 b.) setup_user_keys does some stuff there to figure out the correct
     location for a user's AuthorizedKeysFile . you will probably have
     to split that out to re-use it.

Ultimately, I'm not entirely opposed to just writing the contents of the
user's AuthorizedKeysFile (raw contents as opposed to fingerprints).

We've already made a change in the printing of these for ssh public keys.
The key fingerprint is really something for humans. the whole entry is
longer, but more useful in some cases also.