Ssh – Is there such a thing as a signed SSH keypair

Securityssh

We are transferring files to a remote server in our application and the required method of authentication is to use SSH keys.

So, I created my keypair using ssh-keygen and submitted my public key for insertion into the remote host's authorized_keys file. However, this was rejected by IT Security who said they'd generate the keypair for me and send me the private key. Reason: "We need the SSH keys to be signed by IT Security team. This is to ensure we have some lead in trackings and accountability."

Obviously, I have issues with this. Having the private key generated by someone else means that I can have that person masquerading as me without me knowing. I'm trying to find ways to refute this argument.

As far as I can google, there does not seem to be any known way to sign the keys such that it helps in tracking a person who signed on. The fact that I submitted my public key means that I own the key and anybody who signs on to the remote server with that key is by default identified as myself. How would signing help? And how would they sign anyways?

Someone please clue me in if I'm wrong, thanks!


Ok, now that we've determined that there's no way SSH keys can be signed, I need to show IT Security how they can actually keep track of who's been logging in (gotta be constructive, I guess, if not the high-handedness starts). On my own server, I set sshd's LogLevel to DEBUG. So now when I log in, I can see the following snippet:

Found matching DSA key: xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx

This seems to be a hash value. How do I relate this back to which public key in the authorized_keys file was used? I know there's another line that says:

debug1: matching key found: file /home/bofh/.ssh/authorized_keys2, line 1

but this is not as useful as the line numbers can be easily changed if I were to insert a key at the top of the file, pushing the original keys down.

Thanks!

Best Answer

In the time since you asked your question, the universe has changed.

Openssh5.4 added support for exactly the kind of certificates you were after. See the release notes at http://www.openssh.org/txt/release-5.4 (and the man pages) for more information, or if you really want to be insane, look at PROTOCOL.certkeys for the gory details