Sign up ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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.


share|improve this question
Maybe they'll print the keys, sign it (on paper) and then file it away? – innaM Jul 22 '09 at 6:25
The hash value you get is most likely the so called fingerprint of the key. I recommend checking the openssh manual on how you can list these fingerprints. – Niels Basjes Jul 23 '09 at 18:36
The most likely reason this policy is in place is that they actually want to be able to impersonate you if needed. The signing argument is just BS to make it sound plausible to neophytes. Even if they did need to sign the pubkey, they would not need to generate it themselves. – b0fh Jun 14 '11 at 6:49

4 Answers 4

up vote 10 down vote accepted

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 (and the man pages) for more information, or if you really want to be insane, look at PROTOCOL.certkeys for the gory details

share|improve this answer
Just saw this after a very long time... seems legit :) Will try it out, thanks! – feicipet Jan 8 '13 at 9:18

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).

share|improve this answer
+1 you can not sign ssh keys in the same way you can sign PGP or SSL certificates. I'd seek clarification from them. – David Pashley Jul 22 '09 at 7:24

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)
  2. When you want to send something,
    • you first encrypt it with my-key-private
    • then uploaded to the server this encrypted file
  3. 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
  4. effectively, you have signed the file with your private key
  5. they have verified the signature with your public key
  6. 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,
  2. 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.
share|improve this answer
You're thinking of PGP/GnuPG for encrypting files. In this case key signing is normal. The original question is about SSH keys. It would make sense if they were asking for a PGP signed/encrypted SSH key (after verifying and signing each other's PGP keys). – pgs Jul 22 '09 at 6:24
@pgs, I am trying to see what the IT person is targeting here. – nik Jul 22 '09 at 16:25
I'm pretty sure the security guy is confused, but since he's the IT Security guy from my client's company and not my colleague, I need to be a bit more tact and push constructively w/o just laughing at him and saying he's got things mixed up. Yes, it's definitely SSH and not PGP. – feicipet Jul 22 '09 at 16:30
@feicipet, getting tactful is where my last points will help you. – nik Jul 22 '09 at 17:49
@feicipet, your target would be to finally make them realize the minimum they would have to do for correctly achieving their intent. – nik Jul 22 '09 at 17:50

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 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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.