Is there such a thing as a signed SSH keypair?

Question

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!

Answer 1

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

Answer 2

My first impression when reading your question is that the IT person got SSH and SSL mixed up (it must be signed by us) and also doesn't understand how SSL signing really works.

Anyway there is no way an SSH key can be signed (that I know of).

Answer 3

Something is not right in this request.

If it is delivering signed files to the server,
I would expect this to be done at the bare minimum.

1. You create a key-pair for yourself (call this my-key)
   • When you want to send something,
   • you first encrypt it with my-key-private
   • then uploaded to the server this encrypted file
   • Someone at the server has to reverse the process like this,
   • they use your my-key-pub to decrypt the file
   • if you have sent the file, the decrypt will recover it
   • else, they will not get any usable file
   • effectively, you have signed the file with your private key
   • they have verified the signature with your public key
   • the accountability is effected by them confirming you have sent the file

There are other ways to go about doing such things,
However, getting a key-pair generated by someone else is useless as a authentication scheme.
It has a strong implication that you trust them as much as you trust yourself.

---

These are the opening questions you can ask your IT.
If accountability is a concern for the IT,

1. How do they make sure you do not share/loose the key-pair given to you by them? and,
   • How is this key-pair-from-IT concept any different from a password given to you by the IT.
     Why bother with key-pairs at all in that case.

Answer 4

There's no reason you couldn't use X.509 certificates for SSH authentication instead of bare keys -- in fact, I'd much prefer it if OpenSSH worked this way! But, the stock version of OpenSSH doesn't, and it's the dominant implementation these days.

I've seen a few patched versions of OpenSSH floating around which do, and the commercial SSH.com implementation also appears to support X.509 authentication. So, if your organisation is using one of these, requiring that keys be signed by a central authority would make plenty of sense.

That said, there's no excuse for requiring the private key to be generated by a third-party! If they're going the X.509 route, then they should have you generate a keypair and a certificate signing request, just as you'd do with any other X.509 certificate used for SSL, etc.