> 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.
On Fri, 17 Aug 2012, Joshua Harlow wrote:
> So for this I am thinking of a new config module that has the following ssh_fingerprint s: harlowja/ .ssh/id_ rsa.pub configured.
> config.
>
> display_
> - bob
> - /homes/
> ...
>
> 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/
The thing we're interested in is ~/.ssh/ authorized_ keys. 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/
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.